Why is it so hard?
We see that a lot in client work. Usually the issue is not that people have misunderstood a term. It is that the term has never been defined clearly enough for the decision at hand. One department may use a word one way, another department may use it another way, and both versions make sense in their own context. The trouble starts when everyone assumes they are having the same conversation.
That is why we find terminology worth slowing down for. Not because semantics are the point, but because language shapes decisions. It influences scope, governance, measurement, platform choices, design choices and change approaches. When the language is loose, the work tends to get loose with it.
What follows is not meant to be the definitive answer to every term in the industry. Different organisations will frame these things differently, and that is fine. This is simply the way we tend to separate some of the most commonly muddled terms in Lucid work, because we find these distinctions make projects easier to scope, easier to explain and easier to deliver.
Why these differences matter
It can be tempting to wave all this away as wordsmithing, but in practice the consequences are pretty real.
If a team uses “LMS” when what it really wants is stronger discovery and curation, it can end up buying or configuring the wrong platform. If it treats a quick quiz as a full assessment strategy, it may think it has evidence that it does not really have. If a live delivery problem is still being logged as a risk, action can be delayed. If a workshop is actually a webinar, participants feel the mismatch straight away.
The same thing happens at a bigger level. A piece of work gets called a project when it really needs program governance. A future state deck looks polished, but no one has defined the target state in enough detail to build from. Leaders ask for KPIs and receive a dashboard full of useful numbers that are not actually key indicators.
In our experience, clearer language does not solve every problem, but it does make the right conversations easier. It helps teams ask better questions earlier. It makes trade-offs more visible. And it reduces the amount of avoidable friction that comes from people talking past each other.
1. LMS vs LXP vs LCMS vs LRS
These four terms often get bundled together because they all sit somewhere in the digital learning ecosystem. We tend to separate them by the main job each one is there to do.
When we say LMS, we are usually talking about the platform used to assign, deliver and track learning in a controlled way. It is the place that supports enrolments, completions, reminders, compliance evidence and reporting. In many organisations, it is the formal system of record for learning.
When we say LXP, we are usually talking about the front-end experience of finding and engaging with learning. An LXP tends to lean more heavily into discovery, curation, recommendations and learner pull. It can be especially useful when an organisation wants people to explore content more actively, rather than only complete what has been assigned to them.
An LCMS usually sits further behind the scenes. We tend to use that term when the main need is content production at scale: reusable assets, modular content, version control, shared components and more structured content operations.
An LRS becomes relevant when the conversation shifts from course completions into richer activity data. It stores xAPI statements and can help capture learning or performance activity from multiple places, not just browser-based modules in an LMS.
The reason we draw those lines is practical. An LMS can be critical, but it will not automatically solve content discovery or content operations. An LXP may improve the learner front door, but it does not necessarily replace the compliance and administration side of an LMS. An LCMS is not the same thing as learner-facing delivery, and an LRS is only useful if there is a genuine reporting purpose behind the data being collected.
A useful test is to ask: what problem are we actually trying to solve here? Controlled assignment? Better discovery? Scalable content production? Richer activity tracking? Once that becomes clearer, the platform conversation usually gets much easier.
2. SCORM vs xAPI vs cmi5
These three terms can sound like versions of the same thing, but we tend to frame them as different answers to different tracking and launch needs.
SCORM is still the standard many teams know best. In practical terms, it packages browser-based learning so it can launch in an LMS and send back data such as completion, score, time and bookmarking. It remains useful because it is proven and widely supported. For a lot of standard elearning, it still does exactly what is needed.
xAPI opens up a much broader tracking model. Rather than only recording whether someone completed a packaged course, it can capture activity from a range of experiences and systems. That might include simulations, video interactions, coaching activity, apps, assessments or workplace tasks. It gives teams more flexibility, but it also asks for more design discipline.
cmi5 is often the bridge between those worlds. We tend to describe it as a way of using xAPI within an LMS-managed course launch model. For organisations that want a more practical pathway from SCORM-style launching into richer xAPI data, cmi5 can be a helpful middle ground.
Where teams sometimes get stuck is treating these as trend words rather than design choices. Moving to xAPI sounds attractive, but unless there is a clear reason to collect that richer data, plus a shared vocabulary for how it will be reported, it can just create a larger, noisier data set.
Our usual framing is fairly simple: use SCORM when dependable LMS interoperability and standard completion tracking are enough; look to xAPI when you genuinely need broader activity and performance data; and consider cmi5 when you want the structure of LMS-managed launches with the flexibility of xAPI sitting underneath.
3. Capability vs skill vs proficiency
This is one of the most common areas of muddled language, particularly in workforce planning, role design and learning strategy.
We tend to use capability as the broader term. In our work, capability is usually the combination of knowledge, skills, behaviours, tools, judgement and context needed to perform well in a role or function. It is about being able to do the work in the real environment, not just knowing about it in theory.
A skill is narrower. It is a specific learned ability to do something. Skills are usually more discrete and easier to name, practise and assess. Facilitating a meeting, using a system correctly, giving feedback or writing a concise brief are all the kinds of things we would typically describe as skills.
Proficiency is about level. It tells you how well a skill or capability is demonstrated. Someone may have been exposed to a skill, but only at a basic level. Someone else may be able to use it independently and consistently. Another person may be able to coach others in it. That is a proficiency conversation.
The reason this matters is that the layer changes the design response. If an organisation is thinking about future workforce needs, a capability view is often more helpful because it captures the bigger picture. If it is designing targeted practice or assessment, a skill view may be more usable. If it is defining role readiness or progression, proficiency matters a great deal.
We often use “data-informed decision-making” as an example. That is usually not one skill. It is a broader capability that may include interpreting data, asking good questions, understanding risk, using tools properly and applying judgement in context. Within that capability sit specific skills. Proficiency then helps describe the expected depth.
4. Upskilling vs reskilling vs redeployment
These terms sit close together in workforce transformation conversations, but in our experience it helps to keep them separate.
We usually talk about upskilling when a role is still broadly related to a person’s current work, but expectations are rising. The tools may be changing, the complexity may be increasing, or the role may need a broader mix of skills than before. The work is evolving, but there is still continuity.
We use reskilling when the work is changing more substantially and people need a different capability base. The move is not just a lift from where they are. It is a shift into a materially different role or work context.
Redeployment is different again. It is about moving people into different roles, teams or business areas because demand has shifted. That movement may involve upskilling or reskilling, but the move itself is not the learning solution.
This distinction becomes important quite quickly. We have seen organisations describe almost every development need as reskilling, which can make a modest uplift sound more dramatic than it is. We have also seen redeployment treated as though it solves capability by itself, when in reality it only changes where people sit. It does not remove the need for onboarding, support and capability development in the new environment.
A practical way to sort the language is to ask what is changing most. If the person is still doing related work but at a higher or broader level, it is probably upskilling. If they are moving into a substantially different role, it is probably reskilling. If the organisation is primarily shifting talent to where demand now sits, that is redeployment.
5. Current state vs future state vs target state vs transition state
Transformation work loves “state” language, but we often find these terms are used interchangeably when they are actually doing different jobs.
Current state is the baseline. It is what exists now, including the parts that are formal and the parts that are unofficial. That means systems, roles, processes, workarounds, pain points and operational reality. Without a good current state, a lot of design work ends up based on assumption.
Future state is usually more directional. It describes the intended way of working after change, often at a concept level. It is useful for creating alignment around the ambition and helping people understand where things are heading.
We tend to use target state for the version of that future that is defined enough to design and plan against. It is the agreed end-point that can guide decisions about roles, governance, processes, systems and measures.
Transition state is the temporary reality between the old world and the new one. It tends to include interim controls, dual-running arrangements, staged rollout decisions, manual workarounds and extra support arrangements. It is not always tidy, but it is often where some of the most important operational thinking sits.
One of the patterns we see is teams jumping from a broad future state into solution decisions without enough detail in the middle. Another is the transition state being barely discussed at all, even though that is where people actually have to work while the change is underway.
A good transformation conversation usually gets easier when people are explicit about which state they mean. Baseline, direction, designed destination or interim operating reality are not the same thing, and they should not be treated as though they are.
6. Formative assessment vs summative assessment vs knowledge check
Of Assessment language often gets flattened into “quiz”, but that can hide some pretty important design choices.
A knowledge check is usually a quick, low-stakes prompt. It helps confirm whether someone has understood a point, recalled a concept or stayed engaged with the material. It can be very useful, but we would not automatically treat it as strong evidence of competence.
Formative assessment sits within the learning process and is there to support improvement. It gives people feedback while there is still time to practise, adjust and get better. The emphasis is developmental rather than judgement-based.
Summative assessment sits at the end and is there to determine whether the required standard has been met. That is the point at which pass, sign-off or completion decisions usually come into play.
We find the clearest way to separate these is to ask what decision the activity is meant to support. If it is there to reinforce understanding, a knowledge check may be enough. If it is there to help people build skill with feedback, formative assessment makes sense. If it is there to judge whether the learner can perform to the required standard, then summative assessment is usually the right frame.
That matters because some work contexts need stronger evidence than others. A light-touch question may be perfectly fine in an awareness module. It is a different story when the organisation needs confidence that someone can perform a critical task safely or consistently.
7. KPI vs performance indicator vs business metric
Measurement language can become fuzzy because once something lands on a dashboard, it can suddenly feel more important than it really is.
We tend to use performance indicator as the broadest label. It covers any measure that gives a signal about performance. That could include activity levels, progress, completion, quality, time or other operational markers.
A KPI is narrower. In our view, it should be one of a relatively small number of measures that are genuinely key to success. The “K” matters. If every measure is called a KPI, the term stops helping.
A business metric helps link the work to organisational value. That might mean cost, quality, productivity, safety, risk, customer experience, time to competence or another outcome the business actually feels.
This distinction matters a lot in learning and change work. Participation and completion can be useful indicators, but they are not automatically proof of impact. A stronger conversation asks what changed in the business because the learning or change effort happened, and whether that change can be observed in a meaningful metric.
We usually encourage teams to keep a broader set of indicators for operations, a tighter set of KPIs for leadership attention, and a clear line of sight to business metrics so the work is not only reporting activity.
8. Policy vs standard vs procedure vs guideline
These four often get blurred in governance conversations, and when they do, documents become harder to use.
A policy usually sets intent and formal rules. It says what the organisation stands for or requires.
A standard sets a minimum level or requirement that can be checked.
A procedure explains the steps to do the work.
A guideline offers recommended practice and helps people apply judgement with a degree of consistency.
We find these lines useful because each document type plays a different role. When procedural detail is packed into policy, policies become bloated and hard to maintain. When standards are too vague, they stop being testable. When guidelines are treated like rules, people lose clarity about where judgement is still expected.
In practice, good governance usually becomes easier when these artefacts are allowed to do their own jobs rather than trying to do each other’s.
How can organisations align?
The point of drawing these distinctions is not to win a terminology debate. It is to make work easier to understand and easier to deliver.
Different organisations will always use some of these terms differently, and even within the same organisation the language will shift from team to team. That is normal. What matters is not landing on one universal definition for all time. What matters is agreeing what the term means in the context of the decision in front of you.
That is also the thinking behind the broader glossary and reference guide we have built. It is not meant to be the last word on every term in the industry. It is a practical reference point for teams who need a clearer shared vocabulary: something to help people compare language, reduce avoidable confusion and get to better conversations a bit faster.
In our experience, that is usually where better project work starts.
