Skip to content
OWP

2. Terminology and Conventions

2.1 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.

Sections explicitly marked “Non-Normative” are illustrative; they do not impose conformance requirements. Examples are non-normative unless explicitly marked otherwise. All other content is normative.

Code blocks in this document use illustrative JSON to express object structure. The choice of JSON is for readability only; conforming implementations MAY use any wire encoding that preserves the semantics specified herein.

2.2 Document-Specific Terms

For the purposes of this document, the following terms have the meanings defined here. Definitions are summarised in Appendix C.

Worker. An organisational actor with stable identity, bound to exactly one Role at any moment. See §3.1 and §3.2.1.

Role. The charter definition for a class of work. See §3.2.

Signal. A typed stimulus consumed by Workers. See §3.3.

Intent. A typed desired outcome being pursued by a Worker. See §3.4.

Capability. A vendor-neutral invocation surface exposed by a Capability Provider. See §3.5.

Audit Envelope. The signed, append-only record of all events tied to a root Intent. See §3.6 and §9.

Function. A deployable bundle of Mission, Roles, Signal subscriptions, seeded Intents, and Charter. See §4.1.

Workforce. A running instantiation of one or more Functions, comprising actual Workers in roles. See §4.2.

Charter. The composite, machine-readable, runtime-enforced ruleset binding a Workforce: its Roles, their Authority Grants, Escalation Routes, and any attached Compliance Profiles. See §6.7.

Authority Grant. The specification, within a Role, of which actions are permitted. See §3.2.4.

Standing Intent. The persistent objective declared by a Role, used to drive Intent generation. See §3.2.2.

Driver. Implementation-defined logic by which a specific Worker realises decisions required by its Role. The Driver is not specified by this protocol. See §3.1.3.

Capability Provider. A program that registers with a runtime and exposes one or more Capabilities. See §8.

Dispatch. The act of one Worker generating an Intent assigned to another Worker. See §6.4.

Escalation. The act of a Worker handing an Intent (with full context) to a Human Role or to a Worker holding higher authority. See §6.5.

Outcome. The resolved state of an Intent: achieved, refused, escalated, or abandoned. See §6.6.

Compliance Profile. A constraint set attached to a Function to enforce regulatory, contractual, or organisational requirements. See §11.

Evaluation. A signed, structured assessment of one or more Workers’ or Roles’ performance against expectations, computed over a bounded time window from Audit Envelope events. See §12.2.

Recalibration. An Operator-signed proposal, citing one or more Evaluations as evidence, to modify Charter, Worker lifecycle, Capability binding, or Compliance Profile attachment. See §12.4.

Human Role. A first-class Role held by a human actor, distinguished from a Worker Role. See §7.

Architect, Reviewer, Resolver, Operator. The four Human Roles structurally distinguished by this specification. See §7.1, §7.2, §7.3, §7.4.

Runtime. The implementation that enforces the protocol — mediates Capability invocations, authorises Dispatches, signs Audit Envelope events, routes Escalations, computes and signs Evaluations, and applies Recalibrations. The runtime is the trusted enforcement boundary.

2.3 Identifier Conventions

All long-lived identifiers in this protocol are URIs. The following URI schemes are reserved by this specification:

  • worker: — Worker IDs (§3.1.2)
  • role: — Role IDs (§3.2.5)
  • signal: — Signal kind URIs (§3.3.3)
  • intent: — Intent kind URIs (§3.4.3)
  • capability: — Capability kind URIs (§3.5.2)
  • function: — Function IDs (§4.1.4)
  • workforce: — Workforce IDs (§4.2.2)
  • envelope: — Audit Envelope IDs (§9.1)

Per-instance identifiers (Worker IDs, Function IDs, Audit Envelope IDs) are unique within the scope of their issuing authority. Per-kind identifiers (Signal kinds, Intent kinds, Capability kinds) are global URIs and SHOULD resolve to a schema document describing the kind’s payload structure.