Courses, credentials, capabilities — the operating shift

Introduction

A registrar pulls a weekly export from the student information system into a shared drive at 6:00 a.m. on Mondays. The file powers enrollment checks, room scheduling, and billing runs. The column that everything pivots on is the course identifier. The LMS mirrors this world: a course shell is created, enrollments auto-populate, and grades move back when posted. Finance recognizes revenue per course, and analytics reports performance per course. The unit of work is the course because every system made it the unit.

That operational reality set habits. Faculty authored content to fit the course shell. Students navigated a catalog of courses. Administrators budgeted around course counts. Employers scanned resumes for course names or degrees as proxies for skill because that was what the record exposed. A market signal emerged from what the infrastructure could emit.

The structure is shifting. Credentials became portable records—certificates, micro-credentials, badges—that could travel outside the institution. Now, employers and HR systems increasingly select on capabilities: specific, named skills tied to evidence. Work has been decomposed into tasks that map to those skills. Where the course catalog once organized learning and the credential carried the signal, the skills graph now drives the match. Think of it as moving from a catalog (courses) to currency (credentials) to circuitry (capabilities), with each stage changing how energy moves through the system.

I've seen this pattern before. In the late 1990s, the first wave of web-based learning platforms standardized the course as the unit of learning, assessment, and revenue. My work on early systems with the Blackboard team confirmed this; we built around the course because it mirrored the campus's existing operational structure. When extensibility followed via APIs, it proved a core principle: platforms stabilize around a standard unit.

We are at the next standard-setting moment. The unit of organization is moving from courses, through credentials, to capabilities. Each step has operational consequences: data models, assessment, and governance all change. The systems that carry information between education and employment must change too. The rest of this piece documents that arc and what operators need to do now.

How courses became the unit

The first wave of learning systems standardized around the course because the web and campus processes could support that container. In 1997, on the servers for early web learning platforms, we were literally provisioning a course by creating a directory structure, writing metadata to a table, and assigning users a role bound to that course. A URL, a roster, a gradebook, and a content area came with it. The operational benefit was immediate: one permission model, one billing model, one analytics row per student per course.

The administrative center of gravity

Registrars already indexed on courses because transcripts and tuition did. The LMS joined that world rather than asking the institution to re-architect around competencies. The path of least resistance becomes the path of record. When vendors later introduced APIs and frameworks, they gave institutions a way to add functionality to that course shell. The course stayed the primary key.

Lesson — Follow the path of least resistance to find the true unit of work.

To understand why a system is shaped the way it is, look for the unit that requires the least change from adjacent systems. The LMS adopted the course because the registrar, bursar, and faculty already built their processes around it. This alignment reduced friction and accelerated adoption, cementing the course as the digital container for learning.

> Systems teach organizations what to value by what they can count.

The operational consequence was profound. If something wasn’t tied to a course, it had nowhere to live. Informal learning, work-based projects, or cross-course outcomes had to be stuffed into a shell or lived off-system. This made it difficult to aggregate outcomes or present them to an external party.

Assessment and evidence

Assessment mirrored the container. Quizzes, assignments, and discussions aggregated into a course grade. Gradebooks weighted columns to calculate a single output. Evidence—the artifact of learning—lived behind the login inside the course context and disappeared to the outside world when the semester closed. A hiring manager could not see the rubric or the code commit; they got a line on a transcript that said “CS 201 — B+.”

The market signal

Degrees and course lists became the portable signal because they were the only thing provably recorded and governed. Employers used them as proxies for capability. The system didn’t hide skills; it just never modeled them in a way the outside world could consume.

Credentials as market signal

Portable credentials emerged as the bridge between the course container and the labor market’s need for a verifiable signal. Certificates, micro-credentials, licensure, and badges offered a unit that could travel. Importantly, they introduced their own governance: who could issue, what criteria applied, what evidence was attached, and how a third party could validate a credential.

The operational move from course to credential

Once a credential became an object in its own right, systems had to model it. This meant a credential table with fields for issuer, criteria, date earned, expiration, and a link to evidence. The learning platform had to issue it, the registrar had to recognize it, and the receiving party had to verify it. Standards did work here: IMS Global’s Learning Tools Interoperability (LTI) let systems exchange outcomes, Mozilla’s Open Badges defined a portable format, and Comprehensive Learner Record (CLR) efforts provided a richer transcript.

Lesson — Ensure every credential you issue is backed by accessible, verifiable evidence.

A credential’s value is directly tied to the trust a third party has in it. Without a clear link to the work that was done or the rubric that was used, a badge is just a digital sticker. Build systems that not only issue credentials but also host and serve the evidence that proves the earner’s accomplishment.

> A credential without evidence is a logo; a credential with evidence is a signal.

Governance and signal quality

Credentials brought governance questions to the forefront. Who is authorized to issue a credential? What level of evidence must back it? How long does it remain current? Without clear answers, the signal degrades. With clear answers, the signal compounds—employers learn to trust an issuer, and the credential accrues market value.

Economics and productization

Credentials created new product lines. Continuing education divisions designed short, employer-aligned offerings with certificates. Bootcamps scaled by offering job-relevant credentials. Degree programs began to stack credentials, issuing a certificate midway to a master’s. Revenue could now be recognized per credential, and marketing could speak to the signal an employer would read.

Capabilities as operating system

Employers hire for the ability to perform tasks that create value. As work decomposed into smaller, measurable tasks, companies started building capability maps and skills taxonomies. HR systems followed. Workday introduced a skills cloud, and LinkedIn built a skills graph. The unit moved upstream again: not the course that taught it or the credential that attested to it, but the capability itself.

This is the pivot point: where credentials became currency that could move value, capabilities are the circuitry—the wiring diagram that routes power to where work happens.

From learning outcomes to skills statements

Most curricula already have learning outcomes. The shift is to translate those outcomes into skills statements that map to an external taxonomy and can be read by machines. "Can analyze variance in a dataset using Python and pandas" is more actionable than "understands statistics." When an assessment is aligned to that statement and the artifact is captured, the system can assert a capability with evidence.

Lesson — Translate internal learning outcomes into machine-readable skills that hiring systems can parse.

Your curriculum's learning goals are invisible to employers until they are expressed in a shared language. Map program outcomes to an external skills taxonomy that both your systems and HR technology can understand. This act of translation is the first step toward making graduates’ abilities visible in the job market.

> If a capability can’t be parsed by an ATS, it may as well be invisible.

The data model changes shape

In a course-centered world, the gradebook row is the terminal object. In a capability-centered world, the skill assertion becomes the terminal object. Technically, this means:

• Adopting a shared skills taxonomy.
• Storing skill assertions as first-class records: skill ID, proficiency, evidence link, issuer, and timestamp.
• Connecting credentials to the skills they attest to, not just to course names.
• Allowing multiple issuers to assert the same capability about a learner, with provenance.

Assessment becomes evidence generation

Assessment design shifts from weighing columns to generating reusable evidence. Rubrics specify performance levels mapped to skills. Tools capture artifacts with stable URLs and retention policies. Faculty workflows include tagging assessments to skills. When the grade posts, the system also writes skill assertions with links to the artifacts, making them portable beyond the course lifecycle.

Visibility to employment systems

For the capability to matter, it must be visible to hiring systems. That requires machine-readable export and APIs that Application Tracking Systems (ATS) can query. When a learner shares a verifiable badge, the employer’s system can validate the issuer and parse the skills metadata. The operational work here is integration and standard conformance.

How the stack reshapes

Systems reorganize around the unit they privilege. As capabilities become first-class, the stack evolves from content delivery and course administration to skills evidence, portability, and consumption by external systems.

LMS, LXP, and beyond

• LMS: Still the place for instruction and assessment, but now instrumented to emit skill assertions and evidence.
• LXP: Discovery and pathways organized by skills and roles, not course codes.
• SIS/Registrar: Records now include credentials and skills, not just courses and grades.
• Credentialing: Services that issue, host evidence, and support verification.
• HRIS/ATS: Consume skills, match to roles, and feed back demand signals.

Standards as connective tissue

LTI connects tools into the learning flow; xAPI captures activity; Open Badges structures portable credentials; CLR expresses richer records. Operators should select tools that support these standards and test conformance with real employer systems.

The skills graph as backbone

Internally, institutions will need a skills graph: a data structure that maps courses and assessments to skills. This is less a product to buy than a model to maintain. Some platforms provide a built-in graph; others require stitching. Either way, treat it as core data.

> Build your skills graph before you build your dashboards.

Governance that must follow

Infrastructure changes trigger policy questions. Capability signaling will stall without clear governance.

Issuance authority and quality assurance

Who can assert which capabilities? A department? An employer partner? What evidence is minimally sufficient? How are levels defined and calibrated across programs so a “Level 3 Communication” means the same thing in Business and Engineering?

Lesson — Define and publish issuance authority to protect your credential's long-term value.

Before you issue a single skills-based credential, decide who has the authority to grant it and what level of evidence is required. This governance framework is as critical as the technology platform. By making these rules clear and auditable, you build trust and ensure that the signals you send into the market are reliable and durable.

Recency, renewal, and revocation

Skills decay. Governance must specify how long a capability assertion remains current and what renews it. There must be a way to revoke or supersede a capability if evidence is invalidated. This is a technical feature and a policy stance.

Privacy and consent

Making capabilities portable introduces consent boundaries. Learners should control where their data travels. Consent flows must be explicit and revocable. Legal and data teams need to review how evidence is stored and shared so a link doesn’t overexpose personal data.

Transitional architectures that bridge

Most institutions cannot jump straight to a capability-first model. Transitional architectures can bridge the shift without freezing operations.

Crosswalks from courses to skills

Start by mapping program learning outcomes to a skills taxonomy and then map course assessments to those outcomes. Build a crosswalk table that links course and assessment IDs to skill IDs. Pick high-enrollment programs with strong employer ties first.

Evidence capture without replatforming

Use existing tools to capture artifacts: code repositories, e-portfolios, video platforms. The key is stability and retrievability—URLs that don’t break and metadata that travels with the artifact.

Credentials that reference skills

Issue digital credentials that point to the skills asserted and the evidence. Open Badges allow skill tagging and evidence links; Comprehensive Learner Records can carry sections for skills. Even a simple PDF certificate should have a URL that resolves to a verification page with machine-readable metadata.

Lesson — Start the transition with one program, one employer, and one feedback loop.

Do not try to boil the ocean. A successful transition begins with a focused pilot project. Choose a willing program, partner with a specific employer cluster, and build a simple process to map curriculum to skills, generate evidence, and measure the result. Success in this small loop will provide the blueprint for scaling.

Feedback loop to programs

Implement a basic demand loop: collect job postings to rank skills by demand, feed that back to program leads, and adjust assessments to generate evidence for the highest-signal skills. This is a governance and prioritization exercise that can run quarterly.

Economics and changing incentives

Follow the money and the reporting obligations; they expose where operators must adapt.

Pricing and recognition

When the course is the unit, price per seat makes sense. When credentials carry value, price per credential or outcome emerges. Continuing ed divisions already price this way. Financial aid and public funding are beginning to recognize shorter credentials; institutions that can document outcomes gain advantage.

Outcomes-based funding and accountability

States and accreditors are experimenting with outcomes-based models that reward completion and employment. If capabilities are the measured unit, then institutions that can present verifiable capability data will be better positioned. This requires the data model and governance described above.

Employer partnerships

Employers will pay for programs that deliver capabilities they need. The clearer the signal and the faster the iteration loop, the more valuable the partnership. Co-assessed projects, adjuncts from industry, and shared labs all benefit when the capability model is explicit.

An implementation playbook now

Operators need a path that respects current constraints while moving the system forward. Here is a practical sequence.

1) Inventory outcomes and assessments

Select 3–5 programs with clear employer demand. For each course, list learning outcomes and major assessments. Identify which assessments naturally generate artifacts.

2) Adopt or align a taxonomy

Choose a skills taxonomy and normalize naming and levels. Publish definitions so faculty and employers can see the same words.

3) Instrument assessments for evidence

Add rubrics that map criteria to skills. Configure tools to save artifacts to stable locations with metadata. Train faculty on tagging within their existing workflows.

4) Issue credentials with skill tags

Use a credentialing service that supports Open Badges and CLR. Define issuance rules: who approves, what evidence thresholds apply, and how renewals work. Pilot with a small cohort.

5) Build the skills graph

Create the crosswalk tables: outcomes → skills; assessments → skills; credentials → skills. Stand up a simple service that can answer questions about learner skills. Invest in data quality and API access.

6) Integrate with employer systems

Test with an ATS: can it ingest a badge, parse the skills, and validate the issuer? Set up a consented talent pool where graduates can share credentials. Measure match rates.

7) Close the loop and scale

Use demand data to prioritize which assessments generate evidence. Expand to more programs once the model and governance hold. Share outcomes internally to build momentum.

The bet I'd make today

The institutions and employers that will feel ahead in three years will share one trait: they will treat capabilities as the unit of record and design everything else around making those capabilities visible and verifiable.

Here’s what I would build, in order of dependency.

• A maintained skills taxonomy aligned to external vocabularies.
• A service that writes skill assertions with evidence every time an assessment posts.
• A credentialing layer that issues portable, machine-readable credentials referencing those skills.
• Governance that defines issuance, recency, and revocation.
• Integrations that make the signal readable by HR systems and that make employer demand visible to curriculum owners.

This is not a wholesale replacement of the LMS or the SIS. The course will remain the operational container for instruction; the credential will remain a product that students and employers understand. The change is what sits underneath: a capability model that routes energy through the system like a clean circuit, connecting learning to hiring without manual translation.

When we standardized the course shell in the late 1990s, it organized the web era of learning. When credentials went digital, they became currency we could audit. Now, as capabilities become the circuitry, the stack will stabilize around skills as the unit of record. Build for that shape, and the rest of your decisions will line up.

Course shells set our defaults.
Credentials carried the signal.
Capabilities now define the work.

That’s the shift many institutions and employers are feeling — a structural move from courses → credentials → capabilities. It isn’t a slogan. It’s an operating change that touches data models, assessment, governance, and the systems that sit between the LMS and HR.

I’ve lived two turns of this wheel. In 1997, we built CourseInfo so instructors could put a course on the web. When CourseInfo merged with Blackboard in 1998 and later listed on NASDAQ:BBBB in 2004, the course was the unit: rosters, gradebooks, and payments bound to a course. Building Blocks came soon after so others could extend that course-centered core.

Then the signal moved. Registrars, bootcamps, and platforms began issuing credentials that could travel outside the LMS. Badges, certificates, and digital transcripts appeared. Standards like LTI and Open Badges made them portable. The market started selecting on what you could show, not where you sat.

Now employers hire on capabilities. Work is decomposed into skills. HR systems run skills graphs to match people to roles. That pulls learning backward: curricula map to skills; assessments generate evidence; credentials reference the skills; systems read the signal.

What changes operationally:
- Move from course objects to outcome objects
- Map assessments to skills and store evidence
- Issue machine-readable credentials (Open Badges, CLR)
- Adopt a shared skills taxonomy across LMS, SIS, and HRIS
- Govern who can assert a capability, for how long, and with what proof

If you have to pick a starting point, pick the data model. Without a common skills language, the rest becomes custom plumbing.

I wrote the full analysis — history, system implications, and a concrete build plan — for teams deciding what to modernize first. If you own the LMS, SIS, or HR stack, this is for you.

Read it and share with the operator on point for data, assessment, or employer partnerships.

#EdTech #HigherEd #Skills #HRTech