Skip to content
roleALPHA Docs

Competences

Dependencies · Data Nodes

  • Links to: Demands (via REQUIRES), People (via HAS_COMPETENCE), Value creation (via ASSESSED_IN), Roles (via REQUIRES)
  • Linked from: AI agents (via AGENT_USES_COMPETENCE)

Competences model skills in the organization: what can someone do? What does a role require? Where is a competence assessed?

Purpose

Section titled “Purpose”

Competences carry a category (Technical, Leadership, Social, Methodical, Domain) and a level from novice to expert. Competences can be decomposed hierarchically — e.g. “Programming” includes “Python”, “JavaScript”, “SQL”. Persons hold competences, roles require them, value streams assess them.

Default view

Section titled “Default view”

Cards with category and level badges. Filter by category, level, issuing body and validity.

List view

Important relationships

Section titled “Important relationships”

Competences have the richest relationship network among all entity types — four dedicated required-RelTypes:

  • REQUIRES (Role → Competence) — “requires” / “is required by”
  • HAS_COMPETENCE (Person → Competence) — “has competence” / “is competence of”
  • PART_OF (Competence → Competence) — “is part of” / “contains” (hierarchy)
  • ASSESSED_IN (Competence → Value stream) — “is assessed in” / “assesses”

Details: Relationship Types.

Schema to copy

Section titled “Schema to copy”
{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "title": "Category",
      "enum": ["Technical", "Leadership", "Social", "Methodical", "Domain"]
    },
    "level": {
      "type": "string",
      "title": "Level",
      "enum": ["Novice", "Beginner", "Intermediate", "Advanced", "Expert"]
    },
    "certificationBody": { "type": "string", "title": "Issuing body" },
    "validUntil": { "type": "string", "title": "Valid until", "format": "date" },
    "description": { "type": "string", "title": "Description" },
    "tags": { "type": "array", "items": { "type": "string" }, "title": "Tags" }
  }
}

Extension ideas: proficiencyEvidence (evidence records), lastAssessed, renewalCycle. Details: JSON Schema for Entity Types.

The level lives on the edge — and the scale belongs to the tenant

Section titled “The level lives on the edge — and the scale belongs to the tenant”

Which level somebody holds is not stored on the competence but on the relationship between member and competence (has competence, for an AI agent uses competence) — and equally on the relationship through which a demand requires it. The same competence can thus be held by ten people at ten different levels without existing ten times.

The scale is tenant-owned and of arbitrary length: three levels, five, ten, named or numbered. It lives as a picklist on the relationship type and is maintained under Relationship Types. Comparison runs purely on the position in that list.

Changing the order means changing the meaning. Reordering the enum changes every coverage statement retroactively in the tenant — no history preserves the previous state. Renaming is safeguarded; reordering is not.

Two rules that prevent silent errors:

  • One scale for all three relationship types. Requiring and holding must use the same list — otherwise positions from different scales would be compared, and the result would be plausible and wrong.
  • An unknown value means “not comparable”, never “lowest level”. Otherwise the analysis would invent a statement.

A card in the reports tab shows how often this competence is required in open demands and how many members hold it at that level or above — the skill gap in one card.

Detail view

Section titled “Detail view”
  • Category and level badges
  • Tags as chip list
  • Valid-until date — Valid until is marked as a deadline out of the box and reminds you of re-certification in time
  • Persons holding this competence (HAS_COMPETENCE reverse)
  • Roles requiring it (REQUIRES reverse)
  • Parent and child competences (PART_OF)
  • Assessment value streams (ASSESSED_IN)

Detail view

Section titled “Related”