The Gold Standard of Information · Specialist guide
How shared codes keep their meaning across systems, how mappings preserve uncertainty, and how versioned reference data prevents silent reinterpretation.
The transfer test asks whether the reasoning still works when the system, evidence, timing or affected group changes.
Chapter contents
Foundations
Model and method
Implementation
Chapter 1 of 12
Reference data is small but powerful
Reference data is the controlled set of values used to classify other data: country codes, programme types, status values, units, document categories or reason codes. The tables are often small, yet one code can shape millions of records and reports.
A code such as A17 has no safe meaning by itself. Its scheme, definition, owner, validity period and version supply the context. Copying the value without that context turns a compact identifier into an ambiguous token.
The gold standard treats reference data as governed information, not a convenience spreadsheet. Every value has identity, meaning, lifecycle and evidence of use.
Practical check
- Named scheme and accountable owner
- Stable code or persistent concept identifier
- Definition, scope and examples
- Version and effective dates
- Published change and retirement policy
Chapter 2 of 12
Codes, labels and concepts are different
A code identifies a value within a scheme. A label helps people read it. A concept is the meaning the code denotes. Labels may change for clarity or translation while concept identity stays stable; conversely, the same label can hide different concepts.
Do not use display text as a key. “Active” may mean a currently enrolled learner, an enabled account or an unexpired licence. Scheme identity prevents accidental equivalence.
Multilingual labels should be linked to the same concept only when they express the same governed meaning. Translation quality cannot repair an undefined source concept.
| Element | Purpose | May change without new concept? |
|---|---|---|
| Code | Machine identifier within a scheme | Sometimes, but aliases and history are needed |
| Preferred label | Primary human-readable term | Yes, if meaning is unchanged |
| Definition | Boundary of meaning | Only minor clarification |
| Concept identifier | Durable semantic identity | No; changed meaning needs new identity |
Chapter 3 of 12
Code sets need explicit membership rules
A code list should say what population it classifies, whether values are mutually exclusive, whether several may apply, and whether the list is complete. Without these rules, a technically valid code may still be used incorrectly.
Include an explicit treatment for unknown, not applicable, not collected and withheld only when those are legitimate meanings. Do not collapse them into a single catch-all value.
Validation should test both syntax and context. A programme code may exist but be invalid for a date, jurisdiction or learner stage.
Practical check
- Population and decision purpose
- Exclusive or multi-select semantics
- Completeness and residual categories
- Context and date restrictions
- Meaning of missing or suppressed values
Chapter 4 of 12
Identity survives label changes
Concept identifiers should remain stable through spelling, capitalisation and label improvements. New identifiers are warranted when boundaries change enough that old and new uses cannot be interpreted as the same category.
A retired code should not be reassigned. Reuse destroys historical interpretation because old records acquire the new meaning. Preserve aliases and successor relationships instead.
When organisations import external code sets, retain the source scheme and version. A local surrogate may speed joins but must not erase the external identity.
Practical check
- Never reuse a retired code for a new meaning
- Keep aliases distinct from equivalence
- Record predecessor and successor concepts
- Preserve source scheme, authority and version
Chapter 5 of 12
Worked example: mapping programme status
System A uses ENROLLED, LEAVE, COMPLETED and WITHDRAWN. System B uses ACTIVE, INACTIVE and FINISHED. A tempting crosswalk maps ENROLLED to ACTIVE, COMPLETED to FINISHED, and both LEAVE and WITHDRAWN to INACTIVE.
The last mapping loses a critical distinction. Leave is temporary and may preserve entitlement; withdrawal ends participation. It is a many-to-one operational mapping, not exact semantic equivalence.
The safe crosswalk records relation type, direction, purpose and confidence. It may support an aggregate dashboard while being forbidden for eligibility decisions.
| Source | Target | Relation | Permitted use |
|---|---|---|---|
| ENROLLED | ACTIVE | close operational match | Current participation dashboard |
| COMPLETED | FINISHED | close match | Completion reporting |
| LEAVE | INACTIVE | broader target | Aggregate count only |
| WITHDRAWN | INACTIVE | broader target | Aggregate count only |
Chapter 6 of 12
Crosswalk relations carry meaning
A crosswalk should distinguish exact, close, broader, narrower and related mappings. Exact means substitutable for the declared purpose; close signals substantial similarity with a boundary. Broader and narrower mappings expose information loss.
Direction matters. A detailed source can often roll up safely to a broader target, while reversing the mapping requires guessing among several source values.
Mappings also depend on context and version. A relation valid for reporting may be invalid for legal eligibility, and a mapping can change when either scheme evolves.
Practical check
- Relation type, not only target code
- Direction and information loss
- Declared purpose and prohibited uses
- Source and target versions
- Reviewer, evidence and confidence
Chapter 7 of 12
Splits, merges and retirements
When one concept splits into several, old records cannot automatically be assigned to the new children. A successor relation describes the change, but reclassification requires evidence.
When several concepts merge, historical detail should remain available even if new transactions use the merged value. Retiring a code ends new use; it does not delete its past meaning.
Publish a machine-readable change set with effective dates, reasons and migration guidance. Consumers need time to adapt validation and interfaces.
Practical check
- Addition, clarification, split, merge or retirement
- Effective date and transition window
- Historical handling rule
- Consumer impact and migration note
- No automatic backfill without evidence
Chapter 8 of 12
Versioned meaning and as-of use
Reports should be able to identify which code-set version interpreted a record. A current lookup table can silently relabel old data or make a retired code appear invalid.
Store a scheme version or resolve meaning by effective date. For high-stakes use, retain the exact reference snapshot or a reproducible versioned service.
Valid time says when a code or mapping applied to the represented world. Publication time says when the authority released it. Both may matter when changes arrive late.
Practical check
- Version identifier on exports and APIs
- Effective and publication dates
- Historical lookup path
- Reproducible as-of mapping
- Correction and restatement policy
Chapter 9 of 12
Validate crosswalks as transformations
Coverage asks whether every required source value has a governed outcome. Uniqueness asks whether mappings create ambiguity. Round-trip tests reveal information loss when values are mapped there and back.
Do not demand a perfect round trip from an intentionally broader target. Instead, declare the loss and test that it remains within the permitted purpose.
Use examples near boundaries and retired versions. A mapping that works only for current common codes may fail precisely where audit questions arise.
Practical check
- Unmapped and multiply mapped values
- Relation-type distribution
- Round-trip loss by purpose
- Version and boundary cases
- Rejected use outside scope
Chapter 10 of 12
Distribution, caching and contracts
Reference data often appears in files, databases, APIs and application bundles. Every distribution needs a version, checksum or release identifier and a clear refresh rule.
Long caches can preserve obsolete values; uncontrolled live lookups can make a report change between runs. Choose consistency according to the task and retain the version used.
A consumer contract should state how unknown codes are handled. Silent fallback to “Other” hides defects and can change counts.
Practical check
- Authoritative publication endpoint
- Release identifier and integrity check
- Cache and refresh policy
- Unknown-code error path
- Deprecation notice and compatibility window
Chapter 11 of 12
Governance is editorial and technical
Subject experts define meaning; data stewards maintain lifecycle; engineers enforce identifiers and distribution; users report ambiguity. No single role can govern the whole system alone.
A change request should include evidence, affected processes, proposed definition, examples, migration and review. Emergency fixes still need a traceable later review.
Measure unresolved requests, mapping exceptions, obsolete-version use and consumer adoption. Counting codes does not measure trust.
Practical check
- Named decision authority
- Public change log
- Conflict and appeal path
- Consumer notification
- Periodic review of unused and ambiguous values
Chapter 12 of 12
Transfer check: map two location schemes
Map a school’s local area list to an official geographic classification. Start with identifiers and versions, then classify each relation. A school catchment may cross official boundaries, so an exact map may be impossible.
Change the context: a boundary is redrawn while historical enrolments remain. Preserve old meaning, publish successors and choose whether reports use geography at enrolment time or current geography.
A reviewer should reproduce one mapped result from source code, scheme version, relation, target version and purpose. If that chain is missing, the crosswalk is not evidence-ready.
Practical check
- Name both authorities and versions
- State relation and direction
- Preserve historical schemes
- Test information loss
- Record the permitted decision purpose
Advanced cases and implementation boundaries
Scheme namespaces and collisions
The same short code can appear in many schemes. “01” might mean a country, a grade, a transaction type or a reason. Store a scheme identifier with every code and expose it in interfaces where ambiguity could matter. Global uniqueness is unnecessary if the namespace is explicit.
When data is merged, validate the pair of scheme and code rather than code alone. A warehouse that drops the namespace can join unrelated values while passing simple format checks.
Canonical codes and local aliases
Local systems may need familiar aliases, abbreviations or legacy values. Treat them as inputs resolved to a canonical concept, not as competing authorities. Record the alias source, effective period and any ambiguity.
If one alias can resolve to several concepts, require context or human review. Guessing from frequency makes rare but valid meanings disappear.
Hierarchies and polyhierarchy
Reference concepts often sit in hierarchies: a district belongs to a region, a product to a category. Some concepts legitimately have more than one broader relation. Do not force a tree when the domain is a graph.
Roll-up reports must specify which hierarchy and version they use. A total calculated through two parent paths can double count unless the aggregation rule handles polyhierarchy.
Ordering and presentation
Display order is not semantic identity. Codes should not change merely because a list needs a new sequence. Keep sort keys or presentation groups separate from stable identifiers.
Where order carries meaning, such as severity levels, state it explicitly and test comparison operations. Lexical code order is rarely a safe substitute.
Jurisdiction and authority
A code may be valid only under a particular jurisdiction, regulator or organisation. Copying it elsewhere can imply authority that does not exist. Record issuer and scope.
Cross-jurisdiction mappings should expose legal or policy differences. Similar labels do not erase the governing source.
Corrections to reference releases
A release may contain an error. Publish whether the correction replaces the release, creates a new patch version or changes validity retroactively. Consumers need to know whether prior outputs should be restated.
Retain the incorrect release when audit requires it, but mark it superseded and prevent new use. A quiet file replacement breaks integrity checks and historical evidence.
Composite classifications
Some decisions require combinations such as programme plus delivery mode plus learner stage. Resist creating one giant code for every combination if dimensions have independent lifecycles.
Use separate governed fields with combination rules. Composite codes are justified only when the combination itself has stable meaning and authority.
Security and privacy
Reference data is usually non-personal, but small classifications can enable inference when joined to records. Review sensitive status values, rare categories and public publication.
Access control should not hide definitions needed for fair interpretation. Separate public semantic documentation from restricted operational membership where possible.
Deprecation without surprise
Give consumers machine-readable deprecation status, replacement guidance and a future rejection date. Warnings should appear before removal in validation and API responses.
Monitor actual use before ending support. A formally unused code may remain embedded in archived records that still need historical lookup.
Evidence packet
For one release, retain approved specification, change requests, decision minutes, validation results, mapping reviews, published files and integrity hashes. Link them with a release identifier.
The packet should let a new steward explain why a code exists, what changed and which consumers were notified without reconstructing history from email.
Chapter-by-chapter evidence audit
This audit turns the teaching chapters into a repeatable review. It is intentionally concrete: every conclusion should connect to a record, boundary test and accountable next step.
Audit 1: Reference data is small but powerful
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Named scheme and accountable owner; Stable code or persistent concept identifier; Definition, scope and examples; Version and effective dates; Published change and retirement policy. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 2: Codes, labels and concepts are different
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: . Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 3: Code sets need explicit membership rules
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Population and decision purpose; Exclusive or multi-select semantics; Completeness and residual categories; Context and date restrictions; Meaning of missing or suppressed values. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 4: Identity survives label changes
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Never reuse a retired code for a new meaning; Keep aliases distinct from equivalence; Record predecessor and successor concepts; Preserve source scheme, authority and version. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 5: Worked example: mapping programme status
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: . Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 6: Crosswalk relations carry meaning
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Relation type, not only target code; Direction and information loss; Declared purpose and prohibited uses; Source and target versions; Reviewer, evidence and confidence. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 7: Splits, merges and retirements
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Addition, clarification, split, merge or retirement; Effective date and transition window; Historical handling rule; Consumer impact and migration note; No automatic backfill without evidence. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 8: Versioned meaning and as-of use
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Version identifier on exports and APIs; Effective and publication dates; Historical lookup path; Reproducible as-of mapping; Correction and restatement policy. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 9: Validate crosswalks as transformations
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Unmapped and multiply mapped values; Relation-type distribution; Round-trip loss by purpose; Version and boundary cases; Rejected use outside scope. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 10: Distribution, caching and contracts
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Authoritative publication endpoint; Release identifier and integrity check; Cache and refresh policy; Unknown-code error path; Deprecation notice and compatibility window. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 11: Governance is editorial and technical
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Named decision authority; Public change log; Conflict and appeal path; Consumer notification; Periodic review of unused and ambiguous values. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Audit 12: Transfer check: map two location schemes
A warning sign is that teams can use the value but cannot explain its authority, version, boundary or mapping loss. Review this chapter through the concrete checks already defined: Name both authorities and versions; State relation and direction; Preserve historical schemes; Test information loss; Record the permitted decision purpose. Record which check is satisfied, which remains uncertain and who owns the next action.
Retain one worked record showing the input, governing definition or information set, transformation or decision, result and reviewer. Change one material condition and repeat the test. If the conclusion changes, explain whether that sensitivity is intended, evidence-led and acceptable.
Field workbook: turn the idea into evidence
Use these prompts to produce a reviewable specification, worked test and approval record. Each step should leave evidence another person can inspect without relying on private memory.
Specification before software
Write the scheme purpose, population, authority, code syntax, concept identity rule, version policy and consumer obligations before choosing a tool. Include one example of a valid value, an invalid value and a value that is valid only in a restricted context.
A compact specification prevents users from treating a convenient export as the authority. It also lets procurement and engineering teams compare products against the same semantic contract.
Mapping review board
Give mapping decisions a named owner and at least one reviewer who understands the source and target domains. Record disagreement, evidence and permitted use rather than forcing consensus into an unqualified one-to-one table.
Review high-impact many-to-one mappings more often than exact administrative aliases. The risk is proportional to lost distinction and decision consequence, not to the number of rows.
Historical migration drill
Take one retired value, one split concept and one merged concept. Show how an old record is interpreted today, how a new record is validated, and which transformations are forbidden without additional evidence.
If the team cannot reconstruct the old meaning without opening an archived spreadsheet, the publication process is incomplete. Put versions, definitions and mappings in the governed release.
Crosswalk confidence
Confidence should describe evidence for the relation and its purpose. It is not a universal score. A close match may be high-confidence for aggregated statistics but unacceptable for individual eligibility.
Store explanatory notes and test cases beside the relation. A number without rationale invites future users to treat confidence as precision.
API and export tests
Test that an API and downloaded file expose the same concept identifiers, versions, effective dates and retirement status. Validate pagination, encoding, language tags and unknown-code responses.
A consumer should be able to cache a release and later prove which meaning was used. Mutable endpoints without release identifiers defeat that requirement.
Human-readable publication
Publish definitions, examples, change history and contact or issue route in a form non-specialists can use. Machine-readable RDF or JSON does not replace clear editorial explanation.
Users often discover ambiguity first. A visible feedback path turns local workarounds into governed improvements.
Practice task
Create a five-value attendance code set, then map it to a three-value dashboard classification. Mark exact, broader and unmapped relations. Add effective dates and a retirement.
Change one source definition without changing its label. Decide whether this is clarification or new concept identity, then show the effect on historical reports.
Approval card
Approve only when identity, definition, authority, version, lifecycle, mapping purpose, loss, validation and publication are documented. Require one independent reviewer to reproduce a historical lookup.
If meaning depends on oral memory or a filename such as final-v3-revised, the reference data is not ready.
Reading routes across the eduKate ecosystem
Begin with The Gold Standard of Information. Place this specialist guide inside The Gold Standard of Education: Learning Transfers into Life, then use the How X Works hub to compare methods across domains.
Related specialist guides
Frequently asked questions
Is reference data the same as master data?
Reference data classifies other data; master data usually represents core entities such as people, products or organisations. They interact but have different governance.
Can two identical labels be treated as the same code?
No. Compare definitions, scope, authority, date and intended use. Identical text can denote different concepts.
Should retired codes be deleted?
Usually not when historical records use them. End new use, retain their meaning and publish successor relationships.
What makes a crosswalk exact?
Substitutability for the declared purpose and context, supported by definitions—not visual similarity or shared labels.
How should unknown codes be handled?
Reject, quarantine or route them for governance according to the contract. Silent conversion to Other is rarely safe.
Why version reference data?
Because code meanings and mappings change. Versioning makes historical interpretation and report reproduction possible.
Authoritative sources
- W3C SKOS Simple Knowledge Organization System Reference
- W3C Data Catalog Vocabulary Version 3
- Interoperable Europe SEMIC toolkit
- European Commission e Government Core Vocabularies handbook
Source links support the technical or institutional foundations. The worked examples and transfer checks are original teaching constructions, not reports of real people or cases.