Workforce graph modeling is the practice of representing people, positions, roles, organizational units, skills, proficiency evidence, reporting relationships, demand, and policy as connected, time-aware graph objects so workforce decisions can be reasoned across systems and executed with traceability.
Start with the workforce decision, not the org chart #
The first stage is to define the decision that the graph must improve. Internal mobility, project staffing, succession, workforce planning, and learning recommendations sound related, but each requires a different situation. A staffing decision needs availability, location, proficiency evidence, recency, demand timing, and policy. Succession requires role criticality, readiness, experience, mobility constraints, and potential conflicts. If the model begins with every field in the HRIS, it will reproduce system structure rather than decision context.
Create a decision card before drawing the schema: decision owner, trigger, entities involved, evidence required, policy constraints, permitted actions, and measurable outcome. This artifact becomes the boundary of the first domain and the acceptance test for every node and edge that follows.
Stage 1: separate identity, work, and structure #
Model Person, Position, Role, Assignment, and Organization Unit separately. A person can hold more than one assignment; a position can be vacant; a role can describe expected capability across many positions; and an organizational unit can be reorganized without changing the identity of every person inside it. Reporting relationships are best attached to positions or assignments with effective dates, because the manager of a role is an organizational fact, not an immutable property of the individual.
Checklist
Confirm that the model can represent a vacancy, an acting assignment, a contractor, a matrix reporting line, a future-dated transfer, and a historical organization chart. If any of those require overwriting the person record, the structure is too flat.
Stage 2: build a governed skill taxonomy #
A skill is a canonical concept, not every phrase found in a profile. Create one governed skill entity with preferred label, synonyms, broader and narrower relationships, domain, lifecycle status, and links to roles or work. Distinguish skills from knowledge areas, tools, certifications, languages, responsibilities, and outcomes. They can be connected, but collapsing them creates false equivalence and weak matching.
| Layer | What it represents | Example | Modeling rule |
|---|---|---|---|
| Capability domain | Broad family of work | Data Engineering | Use for navigation, not direct proficiency |
| Skill | Deployable capability | Change Data Capture | Canonical entity with synonyms |
| Tool or platform | Technology context | Kafka | Connect to skills; do not always treat as the skill itself |
| Certification | Evidence or credential | Cloud certification | Evidence for capability, with issue and expiry dates |
| Role requirement | Expected skill and level | Senior Data Engineer requires CDC | Dated relationship with importance and target level |
Stage 3: model proficiency as evidence #
Do not attach one permanent proficiency value to a person. Model a person-skill relationship with multiple evidence records: manager validation, assessment, recent project use, certification, learning completion, work artifact, or self-rating. Each evidence item needs source, method, confidence, date, and validity. A decision-specific score can then be calculated by the Decision Layer using declared rules rather than hidden inside the graph.
Recency and usage matter. A highly rated skill last used five years ago may not be equivalent to a moderately rated skill used every week. The graph should preserve the facts; the decision policy decides how to weigh them.
Stage 4: connect capability to demand and availability #
Skills become operational only when connected to work. Model demands, projects, tasks, or roles with required skills, importance, acceptable alternatives, start date, duration, location, and clearance constraints. Availability should be derived from assignments and capacity, not stored as a yes-or-no profile field. The Context Harness applies employment, geography, privacy, and fairness policies before candidate situations are assembled.
Three industry patterns
Professional services. Project demands connect skill requirements to verified project history and future availability. Manufacturing. Plant roles connect equipment skills, safety certifications, shift eligibility, and local labor rules. Banking. Regulated roles connect product knowledge, licenses, separation-of-duty policy, and jurisdiction.
A realistic enterprise scenario #
A global services company needs to staff a six-month data modernization program across three regions. The HRIS knows employees and reporting lines; the staffing tool knows assignments; the learning platform knows courses; project systems know recent work; and managers maintain local spreadsheets of trusted specialists.
Understand. The Context Graph Engine resolves people across systems, separates positions from assignments, maps profile variants to canonical skills, attaches project evidence with recency, and calculates future availability from assignment end dates. The Context Harness removes candidates who cannot be considered because of location, employment type, or client restrictions.
Decide. The Decision Layer compares required skills with evidence, identifies exact and adjacent capability, exposes uncertainty, and produces a ranked slate with explanations rather than a black-box score. It also identifies skill gaps that can be closed before the project start.
Execute. Approved staffing actions flow through the Execution Grid to the staffing system; learning actions are assigned where policy permits; outcomes return to the graph as new evidence. The result is not a one-time match but a continuously improving workforce situation.
Common mistakes to avoid #
- Copying the HRIS schema into a graph and calling it a workforce model.
- Making the person record carry position, manager, role, and organization history as mutable fields.
- Treating every profile phrase as a distinct skill instead of governing synonyms and lifecycle.
- Using self-rating as the only proficiency evidence.
- Storing an unexplained composite score in the graph instead of facts and evidence.
- Ignoring privacy, fairness, labor, and jurisdiction policies until after matching.
How OpenKnowra approaches this #
The educational model above is platform-neutral. OpenKnowra implements it through the Context Graph Engine, which resolves workforce entities, preserves temporal reporting and assignment relationships, governs the skill ontology, and attaches lineage to proficiency evidence. The Context Harness applies privacy and eligibility policy; the Decision Layer assembles and evaluates staffing or mobility situations; and the Execution Grid writes approved actions back to systems of record.
The preferred starting point is one workforce decision, one governed skill slice, and the minimum connected systems needed to prove an Understand-Decide-Execute loop.