Skip to content
OWP

7. Human Roles

Human actors participate in the protocol as first-class entities. Their participation is structurally distinguished from Worker participation: human authority is conferred legally, socially, or organisationally, not configurably. The protocol therefore treats Human Roles separately from Worker Roles.

A single human principal MAY concurrently hold multiple Human Roles. The combination Architect+Reviewer, Operator+Reviewer, or any pairing across §7.1–§7.4 is permissible and common in small organisations; large organisations SHOULD separate the roles where independence between them is structurally important (e.g. an Operator co-signing a Recalibration of a Function whose Charter the same principal also originally authored as Architect). Human-Role multi-binding is the standard organisational pattern and is supported here. It is distinct from Worker binding: Workers (§3.1) are bound to exactly one Role at any moment per §3.2.1.

The mechanism by which a runtime tracks which principal holds which Human Role for which Workforce is the Human Role Binding artefact specified in §4.2.5. Every Human Role authority described in §7.1–§7.4 is exercisable only by principals with an active binding for the relevant Workforce; the runtime MUST resolve the binding at every point of authority invocation and MUST refuse signatures from principals lacking the required binding.

7.1 Architects

An Architect is a human who authors Functions, Roles, and Charters. The Architect is the source of the standing intent: the reason the Workforce exists.

The protocol surfaces Architects through:

  • Function authoring: only an Architect may sign a Function (§4.1.5).
  • Charter amendment: changes to a deployed Workforce’s Charter MUST be signed by an Architect.

The protocol does not specify Architect tooling. Architects participate through whatever authoring environment the operating organisation provides.

7.2 Reviewers

A Reviewer is a human who reviews Outcomes and exercises judgment that exceeds the scope of any Worker. Reviewers are the reflective surface of the Workforce.

Reviewer participation is structured around:

  • Audit Envelope review. A Reviewer MAY inspect any Audit Envelope of a Function for which they hold Reviewer Role.
  • Outcome refusal. A Reviewer MAY refuse a Worker’s Outcome before it is acted on, raising an Escalation. The runtime MUST treat Reviewer refusal as an authoritative event.
  • Pattern surfacing. A Reviewer MAY review aggregated patterns across Audit Envelopes (Worker behaviour over time, recurrent refusal categories, cost anomalies).

Reviewer authority is asymmetric: Reviewers MAY refuse, but MAY NOT positively author Outcomes. The latter is the work of Workers (or, in escalation, of Resolvers).

7.3 Resolvers

A Resolver is a human who handles work that exceeds the Workforce — typically because human-to-human relationship, judgment, or trust is required. Resolvers are escalation targets for Intents that cannot be resolved within the Workforce.

Resolver participation is structured around:

  • Escalation acceptance. A Resolver accepts an escalated Intent, exercises judgment, and records an Outcome. The Outcome flows back through the Escalation chain per §6.5.
  • Channel-native interaction. Resolvers interact through their existing channels (Slack, email, ticketing, calendar, voice). The protocol MUST NOT require Resolvers to operate within a bespoke OWP-specific user interface; routing to existing channels is a requirement on Capability Providers (§7.5).

7.4 Operators

An Operator is a human accountable for the continued performance of one or more Roles or Workers in a Workforce over time. Where Architects design Functions and Reviewers refuse Outcomes, Operators observe, evaluate, and propose recalibrations. Operators are the management surface of the Workforce.

Operator participation is structured around:

  • Evaluation commissioning. An Operator MAY commission an Evaluation (§12) over any scope they hold authority over: a Worker instance, a Role, a Role within a deployment context, a Role version, a Function, or a Function version.
  • Recalibration proposal. An Operator MAY sign a Recalibration (§12.4) citing one or more Evaluations as evidence. A Recalibration is a proposal; where it amends a Charter element (Standing Intent, Authority Grant, Intent Grammar, Signal Subscriptions, Escalation Routes), the Recalibration MUST be co-signed by an Architect per §7.1 before the runtime applies it.
  • Lifecycle action. An Operator MAY initiate Worker decommissioning per §12.5 within their assigned scope. Decommissioning of an entire Role or Function follows the Charter amendment path and requires Architect co-signature.
  • Compliance Profile attachment. An Operator MAY attach or detach Compliance Profiles to Functions in their scope, subject to organisational policy. Attachment of a Profile that adds constraints does not require Architect co-signature; detachment does.

Operator authority is intentionally bounded. Operators cannot author Functions or Roles (Architect-only, §7.1) and cannot refuse Outcomes (Reviewer-only, §7.2). The same human MAY hold multiple Human Roles in small organisations; large organisations SHOULD separate Operator from Architect so that recalibration evidence is independently reviewed by the original author of the Charter being amended.

The Operator Role is the OWP analogue of the operational manager in a human organisation: the person accountable for ongoing performance of the team, distinct from the person who designed the team’s job description.

7.5 Human-Surface Requirements

Human Capabilities (§3.5.3) MUST be implemented in a manner that meets humans in their existing channels. The protocol does not specify the channels (Slack, email, Linear, Teams, ServiceNow, voice, postal mail, in-person) — these are deployment concerns — but it specifies that:

  • A Human Capability invocation MUST result in a stimulus delivered to the human through a channel they already use, with sufficient context to act.
  • The human’s response, when produced, MUST flow back into the Workforce as a Capability response (and, where appropriate, as an Internal Signal).
  • Human Capability invocations MUST be tracked in the Audit Envelope with the same fidelity as model and tool Capabilities.
  • Human cost MAY be modelled in the Cost Record at the deployment’s chosen granularity (per-message, per-minute, per-decision); it MUST be recorded.

The protocol’s position on this is unequivocal: humans are not required to adopt new tooling to participate. They participate through the surfaces they already inhabit. Implementations that violate this requirement are not conforming.