JobFrame · Matching

Job matching you can check — not a black box.

Every JobFrame match is computed against a in four measurable spaces, carries a and its evidence, and says “I don’t know” instead of guessing. Here is exactly how it works.

Why matching goes wrong everywhere else

Most tools match jobs by comparing title strings. “Customer Success Manager” matches “Customer Service Manager”, a “Ninja” matches nothing sensible, and the errors are silent — they surface months later inside a pay decision. String similarity is not job similarity.

Measure the job, not the string (the four spaces)

JobFrame gives every canonical role coordinates in four measurable spaces — so “how similar are these two jobs?” has a computed answer, like Delta-E for color.

Structural

live

where the role sits: universal level plus family / function / focus.

Content

live

what the work involves: skills, knowledge and activities from public data.

Pay

live

where it sits on the modeled pay surface, fit from real survey data.

Semantic

live

what its description means, as frozen numeric vectors of the profile prose.

nearest neighbors — structuraledition structural@1 · tolerance 0.3
nearest neighbors — contentedition content@1 · tolerance 0.4

Three answers, honestly (the 3-state rule)

Confident

within ; proceeds automatically, evidence attached.

Needs review

plausible but borderline; goes to a human with ranked candidates, never silently accepted.

No confident match

stated plainly. JobFrame refuses to force a match it can’t defend.

Forced-choice matchers are wrong quietly. A matcher that can abstain is wrong loudly — and loud errors get fixed.

How a messy title actually resolves

An inbound job is resolved by multiple signals, not one string: exact alias lookup against the canonical dictionary; token overlap with seniority-aware level inference; your own level codes crosswalked by pay signal (a level’s observed pay is stronger evidence than its name); and your function labels mapped through a reviewed that abstains on ambiguous cases rather than guessing. Each signal contributes evidence; the result carries all of it.

Frozen editions + the certification trail

Coordinates and matches belong to dated, versioned — a match computed today means the same thing next quarter. And the data underneath is adversarially verified: every wired crosswalk mapping survived independent challenge before serving. The verification trail is committed and public.

Editionsstructural@1(live)content@1(live)pay@2(live)semantic@1(live)

Read the verification trail: canon-verify trail (JSON) · The no-LLM serving guarantee behind it: peopleanalyst.com/trust/no-llm-serving

Matches that improve because people confirm them

Every mapping decision is logged with its prediction and evidence, and joined to what reviewers actually chose. Confirmations from the people in the roles feed learned weights back into the matcher — so the system gets measurably better at your jobs, and match quality becomes a statistic we can publish, not a claim.

JobFrame Matching — the one-page version

  • The four spaces — structural (where the role sits) · content (what the work involves) · pay (where it sits on the modeled pay surface) · semantic (what its description means).
  • The 3-state rule — confident · needs review · no confident match. JobFrame refuses to force a match it can’t defend.
  • Multi-signal resolution — an inbound job is resolved by multiple signals, not one string.
  • Frozen editions — a match computed today means the same thing next quarter.
  • Certified data — every wired crosswalk mapping survived independent challenge before serving.
  • Confirmation loop — confirmations from the people in the roles feed learned weights back into the matcher.
  • Never charged: referencing the codes; reading your own past mappings.

peopleanalyst.com/jobframe/matching