Building a Deterministic JD Analyser: From Task Matching to Hireability Memos
Executive Summary
The JD analyser no longer exists to say “your brief matched these tasks.”
Its current job is more commercially useful:
- identify what role the JD is actually trying to hire
- show which failure modes will make interviews drift
- generate a founder-ready memo on what to rewrite now
- produce a marketplace-ready demand packet that can later feed sourcing
The important doctrinal point has not changed:
- the website is not the constitutional owner of capability semantics
- the GFE Skill System remains the source of truth for levels, tasks, processes, KPIs, and crosswalks
- the analyser is only as strong as the manifest generated from that canon
Why the old shape was not enough
Task matching alone is interesting, but it is not sufficient.
A hiring manager does not mainly need:
- more task IDs
- a prettier scorecard
- another vague “recommended interview plan”
They need to know:
- is this role hireable as written
- where will the interview loop drift
- what proof should the candidate actually show
- whether GFE should help rewrite the role, source against it, or both
That is why the analyser had to move from task matcher to hireability diagnostic.
The current architecture
The current analyser uses a generated manifest built from the live Skill System:
- levels
- tasks
- processes
- KPI definitions
- valuation layers
- interview-question mappings
- teardown failure modes from the website
This manifest is then consumed by a shared deterministic core that:
- normalizes JD language
- scores task and process relevance
- classifies role signature and ladder level
- detects hiring failure modes
- generates:
- diagnostic
- founder memo
- marketplace packet
- interview pack
- CTA branch
What changed conceptually
The analyser now treats a JD as a demand-side operating brief, not as a blob of keywords.
That means the tool asks:
- what outcomes are owned
- what level of operator is implied
- what interfaces and cadences must exist for the role to hold
- what proof should separate a real operator from a keyword candidate
- how the role should be represented to a future talent marketplace
This is closer to how an actual hiring system should reason.
Failure modes as first-class output
The most important improvement is that failure modes are now explicit, not buried inside generic risk text.
Current deterministic failure modes include:
- mixed seniority
- missing KPI tree
- missing interfaces and handoffs
- no operating cadence
- tooling without governance
- undefined decision rights
- market or geo ambiguity
These map better to how real hiring drift happens:
- the role mixes IC and leadership scope
- the metrics are not stable
- the handoffs are implicit
- the operator is asked to redesign a system without authority
Why the marketplace packet matters
The Skill System is not only a content taxonomy. It is the beginning of a labor-market API.
That means a JD analyser should not stop at critique. It should also produce a structured output that can later be used for:
- sourcing
- matching
- role normalization
- crosswalk-based interpretation
The marketplace packet is the first demand-side version of that:
- primary role signature
- adjacent signatures
- must-have tasks
- required processes
- KPI ownership
- proof artifacts
- top task crosswalks
What this does for the website
Commercially, the new analyser supports a cleaner story:
- “your JD can be better”
- “here is what will make hiring drift”
- “here is the operator signature you are actually looking for”
- “we can help you rewrite the role and hire against it”
That is stronger than “paste a JD and get a scorecard.”
What remains true
This whitepaper still does not claim that:
- the website certifies operators
- deterministic analysis alone creates recruiter-grade certainty
- the website itself defines the canonical ladder
The analyser is explainable and useful because it is grounded. It is not magical because it is deterministic.
Closing
The strongest version of this product is not one that pretends to know everything.
It is one that stays aligned to the Skill System, makes hiring ambiguity legible, and produces outputs a founder can actually use:
- a better brief
- a better interview bar
- a cleaner operator signature
That is why the analyser now optimizes for hireability, not just matching.