Working with Enumerations and Translation in the LIF Data Model

[kelhoyland]

Context

The LIF data model is established and reflects stakeholder consensus on the contents of a portable learner record. It was intentionally designed to prioritize losslessness and extensibility, enabling translation across diverse systems and standards without prematurely constraining valid source data.

As part of that design, the core LIF model generally avoids hard-coded enumerations. This is a deliberate choice: constraints and normalization are expected to be applied through translation, configuration, or implementation-specific logic, rather than enforced in the shared core model.

This discussion is not about changing the LIF data model. It is about aligning on how to work effectively with the model as it exists, especially when implementers want validation, consistency, or preferred value sets.

Discussion Questions

1. How are you handling enumerations when implementing LIF? (e.g., during translation, downstream normalization, profiles, or app-level validation)
2. Where do constraints add the most value in practice? Ingestion, API boundaries, wallets, AI agents, or other consuming systems?
3. What challenges have you encountered due to the lack of enumerations in the core model?
4. What guidance or examples would make implementation easier? (e.g., reference translations, recommended value sets, use-case profiles)
5. How should LIF document “recommended practices” without making them mandatory?

Goal

Surface real-world implementation patterns and lessons learned so the community can develop shared guidance—without compromising the principles the model was built on.

If you’re implementing LIF (or planning to), we’d love to hear concrete examples, tradeoffs, or open questions.