Skill Signal Analysis API Use Case

Problem

Job text often contains scattered skill, tool, software, technology, and capability signals. Downstream workflows need those signals normalized and connected to decision evidence.

How AvelinLabs Helps

Job Analyze and Job Classify detect skill, tool, task, and domain signals in the request. Job Analyze also returns results[].matching_skills for each occupation candidate so a reviewer can see which input-derived capabilities support that match.

Why It Is Different

Input-derived matching_skills are kept separate from the ONET skills and technologies used for occupation enrichment. They are not required to use exact ONET labels, and matching_skills_source identifies how the list was derived. This avoids presenting extracted request terms as a complete occupation profile.

Input Signals

The current job request accepts:

• job title and description
• tools, software, technologies, tasks, and capabilities mentioned in that text

Decision Output

Relevant outputs include:

• root job_signals detected from the request;
• per-result matching_skills and matching_skills_source;
• O*NET occupation skills and technologies used for enrichment;
• quality, weak-signal, confidence, uncertainty, ambiguity, and explanation fields.

An empty or short match list is not proof that a role lacks a skill. It can reflect sparse input or extraction limits. Ask for clearer role text and route material gaps to review rather than treating absence as a workforce fact.

Product Fit

This use case can support workforce analytics, skill intelligence, job enrichment, search relevance, review workflows, and dashboards that need to expose the evidence behind a recommendation or classification.

Implement and verify

See Job Analyze and the Response Field Reference for exact semantics. Use the official job-analysis payload and sanitized fixture for executable coverage.