Roles and tasks

The protocol separates what kind of work is being done from how that work should be carried out.

• TaskDefinition models the unit of work.
• RoleDefinition models the execution persona and operating contract.
• RoleBinding attaches a role to a concrete endpoint.
• TaskExecutionProfile adjusts execution requirements for a particular task/role combination.

Taxonomy V1 role groups

Taxonomy V1 starts with groups so operators and consumers can scan the catalog without loading every task.

Role and task examples

Task IDs follow {role-family}.{task-action}[.{variant}]. The first segment is the primary role family.

The full runtime catalog currently contains 6 groups, 28 roles, 280 task types, 46 capabilities, 9 modalities, and 15 tool classes.

Manifest

• schemaVersion: role-model.taxonomy.schema.v1
• taxonomyVersion: 1.0.0-alpha.1
• classificationContractVersion: role-model.classification.v1
• contentRevision: taxonomy-v1-alpha.1
• entryCounts:
  • groups: 6
  • roles: 28
  • capabilities: 46
  • modalities: 9
  • toolClasses: 15
  • intentPresets: 0
  • taskTypes: 280

Groups

Roles

Task Types

Capabilities

Modalities

Tool Classes

Why roles and tasks are separate

This split lets the protocol express:

• one role supporting multiple tasks
• one task allowing multiple roles
• different tool policies or output contracts for the same capability family
• endpoint-specific activation state via role binding

If roles and tasks were collapsed into one record, those distinctions would be much harder to represent. Groups are not routing roles; they are discovery, UI, and progressive-disclosure objects.

RoleDefinition

Role definitions carry:

• primaryGroupId
• secondaryGroupIds
• task_types_supported
• required_capabilities
• preferred_capabilities
• forbidden_capabilities
• tool_policy
• routing_policy_overrides
• output_contracts
• safety_policy_refs

TaskDefinition

Task definitions carry:

• required_inputs
• required_capabilities
• preferred_capabilities
• quality_metrics
• allowed_roles
• default_benchmark_suites

RoleBinding

Role bindings are what make role support concrete at the endpoint level. Each binding states:

• which role_id is bound to which endpoint_id
• whether the binding is active, disabled, or candidate
• policy overrides
• effective capabilities
• effective task types

If a requested role has a non-active binding for an endpoint, the reference router rejects that endpoint with ROLE_BINDING_INACTIVE.

role_model.intent

Consumers such as Pi can send role_model.intent metadata with role, task, capability, modality, tool-class, confidence, evidence, and alternatives. Role-Model treats Pi-provided taxonomy metadata as advisory unless it comes from an explicit trusted hard constraint. Unknown advisory fields are ignored with diagnostics so stale client metadata does not drop the user's request.

How roles become concrete

Roles are abstract protocol entities until they are bound into routable infrastructure.

That happens through RoleBinding, which binds a role_id to a concrete endpoint_id. Because endpoint identity also carries model lineage, this is how roles become attached to model-serving endpoints in practice.

role-model does not assume that one model permanently owns one role. A role may be active on multiple endpoints, including multiple endpoints serving the same model under different deployment conditions. The router uses those bindings to define the eligible set, then uses observed performance and policy to decide which endpoint actually wins.

TaskExecutionProfile

TaskExecutionProfile is a patch layer with:

• task_type
• role_id
• required_capabilities
• preferred_capabilities
• routing_policy_patch

It exists so the protocol can express that a task performed under a specific role may need a narrower or different execution shape than the generic task definition suggests.

Mapping pattern