> For the complete documentation index, see [llms.txt](https://docs.tabiya.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabiya.org/ethiopia/skills-matching-algorithm.md).

# Skills-matching algorithm

Ethiopia's public employment service is delivered through a network of physical Job Centers managed by MoLS and its digital backbone, the E-LMIS . Tabiya supports the redesign of the Job Centers' workflows and operating procedures and has shared its open-source matching engine with the E-LMIS team, whose engineers are integrating it into their new platform.&#x20;

### Integrating an improved skills-based matching algorithm

Previously, the E-LMIS matched jobseekers to vacancies with a basic, deterministic rule based on skill overlap, and its skills data was a flat list of \~25,000 entries not aligned to any international standard. Tabiya's  matching service replaces this rule-based matching with a skill-to-skill matching algorithm that compares every skill a jobseeker holds against every skill a vacancy requires in a shared semantic space, so that closely related skills, not only identical ones, count toward a match. Each required skill is scored against the jobseeker's nearest equivalent on a continuous 0–1 scale.  Skill similarity is the core signal, which the service then combines with location, jobseeker preferences, education eligibility, and labour-market demand to produce a final ranking.

***

### *How the matching engine works*

Matching runs on a structured skills profile, not keyword search. The engine compares what a person can do against what a vacancy requires, weighs that against what the person wants and how likely an employer is to hire them, and returns a ranked shortlist a counsellor and jobseeker can act on.

{% stepper %}
{% step %}
***Map both sides onto a shared skills taxonomy***

*Jobseeker profiles and vacancy descriptions are resolved onto the same \~14,000 skills repository of the localized Ethiopian taxonomy, so a skill* *described differently on a CV and in a job advert resolves to a single entry.*
{% endstep %}

{% step %}
***Place every skill in a semantic space***

*Each skill is represented as a vector positioned by meaning, letting the engine measure how close any two skills are rather than only whether they are identical. This is what allows related and transferable skills to count toward a match.*
{% endstep %}

{% step %}
***Narrow to a shortlist***

*Every open vacancy is scored for rough relevance against the jobseeker's profile in a single pass. Vacancies the person is not eligible for, or that fall outside the area they can reach, drop out here; the strongest hundred or so continue.*
{% endstep %}

{% step %}
***Score each shortlisted vacancy skill by skill***

*For every skill a vacancy requires, the engine finds the jobseeker's closest skill and scores that pair from 0 to 1. Essential requirements are combined strictly, so a serious gap in a must-have skill pulls the score down and cannot* *be offset by strength elsewhere. Optional skills add credit more gently.*
{% endstep %}

{% step %}
***Re-read the shortlist with a more precise model***

*A second model compares the jobseeker's skills against each shortlisted vacancy's skills directly, rather than* *through summary scores, and reorders the shortlist on that closer reading.*
{% endstep %}

{% step %}
***Combine both sides of the market into one ranking***

*The skill score is combined with the jobseeker's stated preferences and with an estimate of how likely an employer* *is to hire them — essential-skill coverage, wider readiness, and current demand for the role.*&#x20;
{% endstep %}
{% endstepper %}

### &#x20;*Running on models the government has full ownership of:*&#x20;

The matching service depends on models to classify vacancies, place skills in semantic space and to re-read the shortlist. These can be commercial services reached over an API, or open-weight models hosted on infrastructure the government runs. As part of this work, the two teams are testing and optimizing the engines for the second option.

Local deployment keeps jobseekers' personal data on systems the government administers rather than passing it to an external provider, addressing data sovereignty requirements for a national system holding personal records. It also removes the per-request cost of matching, which makes the service more affordable to operate at the volumes a full Job Center network generates.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.tabiya.org/ethiopia/skills-matching-algorithm.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
