Greenbeam logo

Core terminology and definitions

Capability is a structured, contextualised, levelled construct used to describe and specify what effective human ability looks like in a defined work domain.

For Greenbeam, a capability can carry indicators such as:
  • expected outcomes
  • responsibilities
  • accountabilities
  • tasks or activities
  • knowledge
  • skills
  • behaviours
  • tools
Greenbeam uses capability as a deliberate modelling term for an assessment-ready construct. Other frameworks may use skill or competency for a similar construct.
Competence is the evidenced human realisation of a capability at a defined level.

In Greenbeam terms, competence is not just a claim, a self-view, or a rating. It is a justified judgment.
Proficiency is the degree of demonstrated attainment within a capability, usually expressed through levels or descriptors of increasing sophistication, autonomy, complexity, or quality.

In common usage, people often treat competent and proficient as points on a spectrum, with proficient implying a stronger level of demonstrated capability than merely competent.

In Greenbeam's model, that spectrum is defined by the levelled capability construct, while competence is the justified judgment that a person has reached a given point on it.
Skill is a broad ability label, or a narrower method- or instrument-related ability, that is usually not sufficient on its own for reliable competence assessment.

In Greenbeam's model, a skill becomes meaningfully assessable for competence when it is placed inside a defined capability and level context.
Behaviour is an observable pattern in how a person approaches work and interacts with others, influencing how knowledge and skills are applied in practice.

Using SFIA's treatment of behavioural factors as the basis, Greenbeam treats behaviour as a generic attribute that shapes how work is carried out across contexts and levels.

Behaviour can contribute evidence for performance and competence, but it is not, on its own, a capability or a competence judgment.
Tool is an artefact, technology, platform, method or technique used in the exercise of a skill or capability.

Tool familiarity, or evidence of tool use, can contribute to an assessment. The tool itself is not a capability and is not a competence judgment.
Responsibility is a defined area of work, obligation or expected contribution that a person is expected to carry within a capability context.

Responsibility helps specify what someone at a given level is expected to take on, sustain or deliver. It therefore helps shape evidence expectations for competence.
Accountability is answerability for decisions, outcomes, standards or delegated areas of responsibility.

In Greenbeam's model, accountability helps distinguish stronger from weaker capability levels by clarifying where ownership, consequence and judgment sit.
Task is a work activity performed in pursuing the outcomes and discharging the responsibilities and accountabilities associated with a capability level.

Tasks can contribute evidence for competence, but are not meaningful competence judgments on their own. Skills, knowledge, behaviours and tools may be used in performing tasks, but they are not the same thing as the tasks themselves.
Activity is a work action, or set of related actions, carried out in the exercise of a capability.

Greenbeam should prefer task when the work item needs to be described precisely for assessment. Activity is a broader neighbouring term that can still be useful when reflecting external source language.
Knowledge is the body of facts, principles, theories and practices that a person has learned in relation to a field of work or study.

Knowledge informs capability and competence, but knowledge on its own does not demonstrate competence.
Performance is the observed execution of work, including the behaviours demonstrated and the outcomes achieved in a specific role, task or period.

Performance provides evidence for competence, but is not the same thing as competence. A single performance episode may support or weaken a competence claim, but does not by itself settle it in every case.
Occupation is a broader classification grouping of similar roles in a related field of endeavour.

In Greenbeam's internal model, occupation is broader than role and mainly useful for broad workforce grouping and external translation. This is a deliberate reinterpretation of external labour-market usage, where occupations are usually defined through collections of similar jobs.
Role is a reusable organisational template for a type of work, defined by a required pattern of capabilities and levels.

Role sits between framework and position:
  • the framework provides the building blocks
  • the role assembles those building blocks into a demand profile
  • the position is the organisational seat to which the role is assigned
Position is a specific organisational instance or seat of a role within a team or structure, which may be filled or vacant.

Position is the structural object an organisation can recruit to, fill, leave vacant, or analyse for succession, bench strength and resilience.
Role family, or job family in some frameworks, is a workforce-segmentation grouping of related roles that share broadly similar work types, task patterns, or labour-market characteristics.

It is useful for reporting, benchmarking, workforce planning and organisational segmentation. It is not, by itself, a capability mapping construct.

Related system terms

Ontology is a structured concept-and-relationship model used to organise, connect and reuse language about skills, occupations or other related entities.

In this project, a skill ontology is best understood as a reusable language layer for search, matching, suggestion, interoperability and inference. It is not, by itself, a competence-assessment framework.
Ontology-based relatedness is the degree to which two skills, roles or concepts are considered close because of semantic similarity, graph structure, overlapping demand, co-occurrence or transition patterns.

Adjacency can be used as an informal market label for this idea, but it is not Greenbeam's preferred term because it is imprecise and can imply more than the evidence supports.

Greenbeam should prefer language such as:
  • ontology-based relatedness
  • skill similarity
  • association-based inference
  • graph proximity
These describe proximity or overlap. They do not, on their own, establish why a person will succeed in developing or performing a capability.
Commensurability is the property that competence judgments for different people, and for people versus capability requirements, can be interpreted on a calibrated common metric or common capability scale strongly enough to support consistent comparison and controlled aggregation.

In Greenbeam's model, competence is a latent construct inferred from evidence, not something directly observed like a physical quantity. So the measurement only becomes meaningful when it is anchored to a well-defined capability construct and calibrated strongly enough to support:
  • like-for-like comparison with respect to a defined capability and level
  • gap reasoning against a defined requirement
  • controlled aggregation into measures such as coverage or severity
  • optimisation logic that tries to reduce the mismatch between available competence and required capability
Decision use therefore depends on:
  • validity
  • reliability
  • calibration
  • evidence quality
This is one of the clearest ways to distinguish development-grade from decision-grade competence data.
Recourse is the property that a competence judgment can be traced, reviewed, challenged, corrected, and learned from because the capability standard, level, evidence, assessors, and rationale are documented clearly enough to support accountability.

In Greenbeam's model, recourse matters because a stronger measurement system should not only produce a better judgment. It should also make it possible to determine:
  • who made the judgment
  • what capability and level were being judged
  • what evidence was relied upon
  • what rationale connected the evidence to the judgment
  • whether the decision should stand, be corrected, or trigger a process change
This is the accounting-like part of the argument.

Accounting is not superior simply because it deals with numbers. It is stronger because it uses documentation, review, control, and correction practices that make judgments challengeable and improve measurement quality over time.

For Greenbeam, decision-grade competence data depends on both:
  • commensurability
  • recourse
Commensurability makes judgments usable on a common capability frame.

Recourse makes those judgments governable, challengeable, and improvable.

This is also one of Greenbeam's strongest contrasts with weaker skills-cloud approaches.

If the underlying skill definitions are loose and the proficiency descriptors are generic across skills, then disagreement becomes hard to adjudicate. The judgement may still be recordable, but it has weak recourse because there is too little standard, traceability, or capability-specific evidence to determine whether the person, the assessor, or the process got the decision wrong.
  • knowledge is what a person has learned
  • skill is an ability label or a more specific task- or instrument-related ability
  • behaviour influences how work is approached and carried out
  • tool is something used in the exercise of work
  • responsibility expresses what a person is expected to carry or deliver within a capability context
  • accountability expresses where answerability for decisions, outcomes or standards sits
  • task is a work activity carried out in pursuing the outcomes and discharging the responsibilities and accountabilities associated with a capability level
  • activity is a broader neighbouring term for work actions, while Greenbeam prefers task where precision matters
  • position is the concrete organisational seat to which a role is assigned
  • occupation is a broader classification grouping of similar roles
  • role family or job family is a broader workforce-segmentation grouping above individual roles
  • role is a designed capability profile for a recurring type of work
  • capability is the structured, contextualised, levelled construct that defines what good looks like in a work domain
  • proficiency expresses degree of attainment within that capability construct
  • performance is what is actually observed in action
  • competence is the justified judgment that a person realises a capability at the claimed level
  • ontology organises concepts and relations for discovery, matching and interoperability
  • ontology-based relatedness expresses similarity or proximity, not a competence judgment
  • commensurability is what makes competence judgments usable on a calibrated common metric for consistent comparison, controlled aggregation and optimisation
  • recourse is what makes competence judgments challengeable, correctable, and governable through documented accountability
These three terms should stay cleanly separated.
  • a role is the designed template
  • a position is the concrete organisational seat
  • an occupation is the broader internal grouping of similar roles, with an external translation function when needed
Greenbeam should usually work with roles when defining demand, because roles are where organisations decide what good looks like in their context.

ABS OSCA works with occupations, because its purpose is statistical classification across the labour market.

This means Greenbeam should not collapse occupation and role into the same term, even though Greenbeam's internal definition of occupation is more role-centred than the external labour-market standards.

A good practical way to think about them is:
  • occupation answers: what broader class of similar roles does this belong to, and how would that translate outward if needed?
  • role family answers: what broader segmentation or grouping does this role belong to for workforce planning?
  • role answers: what capability profile does this organisation require here?
  • position answers: what seat exists in the structure, filled or vacant?
These three terms need to stay cleanly separated.
  • a task is something a person does
  • a skill is an ability they bring to doing it
  • a tool is something they use while doing it
Example:
  • negotiate supplier terms may be a task in a sourcing capability context
  • negotiation may be treated as a skill label or supporting ability
  • a contract management platform may be one of the tools used in the work
This distinction matters because Greenbeam needs to assess competence in a capability context, not just record that a person has seen a tool or has been associated with a broad skill word.

But Greenbeam should not make tasks primary. Tasks only become meaningful evidence when they are interpreted against the outcomes, responsibilities and accountabilities associated with a capability level. The same task can recur across multiple capabilities and at multiple levels, which is why task completion alone is a weak competence signal.
A capability framework is more useful when the goal is to judge whether a person can perform in a defined work context at a defined level.

That is where Greenbeam needs:
  • context
  • level
  • expected outcomes
  • responsibilities and accountabilities
  • evidence
  • auditability
  • comparability
An ontology is more useful when the goal is to organise and connect language for:
  • search
  • discovery
  • matching
  • interoperability
  • suggestion systems
  • career exploration
  • learning recommendations
This is the key distinction:
  • an ontology is primarily descriptive and relational
  • a capability framework is primarily normative and assessable
The strongest value of competence assessment is not just that it describes an individual.

Its strongest value is that, when done well enough, it gives organisations two things:
  • a calibrated common metric for comparing people and requirements against the same capability construct
  • recourse, so judgments can be traced, challenged, corrected, and used to improve future measurement quality
That is what enables:
  • comparison between people with respect to a defined capability
  • comparison between a person's current competence and a capability requirement
  • substitution reasoning with respect to a defined capability and level
  • controlled aggregation into measures such as severity and team coverage
  • optimisation logic that tries to fit people, teams or successors to capability-defined demand
This is also why weaker assessment can still be useful for development while being too weak for higher-stakes decision use.
  • development-grade assessment may be good enough to help one person grow
  • decision-grade assessment is what allows multiple people and multiple requirements to be compared, combined and deployed with more confidence
So Greenbeam should not collapse capability and competence into the same idea.
  • capability remains the reference construct
  • backed by enough recourse to support accountability, correction, and process learning
That judged relation becomes operationally powerful once it is:
  • commensurable enough for comparison and controlled aggregation
  • backed by enough recourse to support accountability, correction, and process learning
In plainer language:

Greenbeam aims to turn competence into a calibrated common metric, not just a directional rating.

Greenbeam's current evidence supports a stronger assessment design for doing this because it:
  • organises assessment around a structured capability framework
  • captures independent employee and leader judgments
  • scaffolds discussion and reconciliation where those judgments do not match
  • links judgments back to explicit capability definitions and evidence
  • preserves enough traceability that individual judgments and process weaknesses can be reviewed later
This is strong support for a more commensurable and more accountable assessment design. It is not yet the same thing as a fully published psychometric calibration proof in the strongest technical sense.
Ontology-based skill data is legitimately useful when an organisation needs to:
  • search a large population
  • generate candidate pools
  • suggest related roles or learning options
  • identify likely non-matches
  • make rough matching or transition suggestions when no actual capability assessment exists
This is important because Greenbeam should not dismiss ontologies as useless. They are useful for discovery and coarse filtering.
Without contextualised level definitions and evidence, ontology-based skill data is not sufficient on its own for:
  • reliable capability inference
  • reliable competence judgment
  • like-for-like substitution decisions
  • coverage calculations
  • decision-grade gap-to-demand comparison
  • succession or resilience modelling
So the fair Greenbeam claim is:

Ontology-based skill data can help identify plausible candidates and rule out likely non-matches, but it does not by itself justify a competence judgment.
Occupation classifications such as OSCA are useful because they:
  • provide a standard external labour-market structure
  • support statistics, search and interoperability
  • help place roles or work types into a broader external family
But OSCA does not do the same job as a capability framework.

OSCA helps answer:
  • what occupation would this role map to in the labour market?
A capability framework helps answer:
  • what capabilities are required here?
  • at what level?
  • with what tasks, outcomes, responsibilities and evidence expectations?
So occupation is an important adjacent concept, but it does not replace role design or competence assessment.

Practical examples

Negotiation on its own is a skill label.

That label is too broad to support a reliable competence judgment because the work context can differ materially.

Examples:
  • negotiating supplier terms in sourcing
  • negotiating stakeholder trade-offs in stakeholder relationship management
  • negotiating a hostage crisis
All three involve negotiation, but they do not represent the same capability context, the same level expectations, or the same evidence base.

Greenbeam therefore treats the capability context as primary and treats negotiation as something expressed within that capability context.

The task layer is what makes that expression concrete. A person at one level might support stakeholder preparation and routine negotiation tasks, while a person at a higher level might lead the negotiation of complex trade-offs or strategic agreements.
Excel can be a tool label, and in some contexts also a tool-related skill label.

But generic Excel familiarity is not enough to justify a competence judgment.

Examples:
  • using Excel in financial modelling
  • using Excel in operational reporting
  • using Excel in data analysis
These overlap in tool use, but differ in capability context, expected outputs, quality standards, and level expectations.

Again, the task layer helps distinguish the work:
  • building a finance model for investment analysis
  • preparing an operational reporting pack
  • cleaning and analysing data for insight generation
chevron-down