Talent Marketplace vs Skills Intelligence Platform

A talent marketplace answers a matching question: given what we think this person can do and wants to do, which gig, project, mentor, or role fits? Its engine runs on profiles, most of them inferred from job history, resumes, work signals, and self-declared interests. A skills intelligence platform answers a measuring question: what can this person actually do, at what level, as of when, and how do we know? Its engine runs on assessed records with anchored levels, methods, and trained dates.

These are not competing answers. Inference is the right way to build a first skills picture across thousands of people quickly; assessment is the way to verify the parts of that picture that carry consequences. The sound sequence is inference first to bootstrap, assessment second to verify, with the verified levels then feeding every downstream decision, matching included. The mistake is treating the inferred picture as if it were already verified.

For internal mobility, a marketplace does something no skills record can: it creates the supply and demand. Managers post gigs and projects, employees discover work they would never have heard about through a hierarchy, and mentoring and career-path suggestions keep people looking inward before they look outward. At scale, that changes retention and redeployment economics, and the AI matching makes the discovery tolerable for a workforce of tens of thousands.

Marketplaces also carry recruiting and talent-lifecycle reach that a workforce skills platform does not try to match. Connecting external candidates, internal talent, and open roles in one profile model is a real advantage for organizations whose main problem is finding and moving people rather than proving what they can do.

The stop is the profile. An inferred or self-declared skill has no anchored level, no assessment method, and no trained date, so it cannot carry compliance, staff safety-critical work, or survive an audit. A marketplace can suggest that a technician is a fit for a project; it cannot show that the technician performed the procedure unsupervised last quarter and that the qualification is still current.

Fit scores are also not gaps. A fit score compares a profile to an opportunity; a gap compares an assessed level to a role requirement on a defined scale. The first is useful for matching; the second is what a development plan, a training matrix, and a succession readiness view need.

Succession is where the difference shows first. A marketplace can surface three plausible internal candidates for a site operations manager role in seconds. Whether any of them is ready is a different question, answered by comparing each candidate's assessed levels against the role's required levels and reading the dates on the qualifications that decay. Readiness is a gap with a timeline attached, and it has to come from a measured record, not a fit score. The same holds for staffing a shift: a suggestion is helpful, a qualification is required. The methods that produce a defensible level are covered under skills assessment, and what a level has to mean is covered under proficiency levels.

The organizations getting value from both run a loop. The marketplace or an inference engine drafts the skills picture from job architecture, resumes, and work signals. The skills platform verifies the parts that matter through manager and practical assessment, attaches trained dates and evidence, and computes gaps against role requirements. Verified levels flow back to the marketplace, so matching runs on measured proficiency rather than declared interest, and the requirements each role publishes come from a real job architecture rather than a title.

In that loop the marketplace gets better matches and the skills platform gets a broader starting picture than assessment alone would produce. The order matters: verify before you match for anything with consequences, and let matching run on inference where the stakes are exploratory.

Concretely, three things flow between the systems. Role requirements, expressed as skills and required levels, flow from the skills platform into the opportunities the marketplace publishes. Assessed levels, trained dates, and expiries flow into the profiles the marketplace matches on. And the marketplace's own signals, the projects someone completed and the gigs they took, flow back as evidence for the next assessment cycle. Each system does the job it was built for, and neither pretends to do the other's.

• How does a skill get onto a profile, and can we see which skills are inferred versus assessed?
• Does a skill carry a level, and what does the level mean in behavioral terms?
• Can the matching engine read verified levels and trained dates from our skills system, and prefer them over inferred ones?
• What happens to a match when the underlying qualification expires?
• Can you produce an audit-grade record showing who assessed a person's level, how, and when?
• For regulated or safety-critical roles, what stops an inferred skill from being treated as a qualification?