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 (Worker Instance). An organisational actor with stable identity; the instantiation of exactly one Worker Definition at any moment (many Worker Instances : one Worker Definition), which it MAY re-bind per §3.1.7. See §3.1 and §3.2.1.

Worker Definition. The template charter for a class of work (Standing Intent, Signal subscriptions, Authority Grant, Intent Grammar, Escalation Routes), instantiated by many Worker Instances. Formerly Role. 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.

Memory. The governed, typed, evolving substrate a Worker reads and writes — Causal, Episodic, Semantic, Working, Constitutional, Relational (§3.7.2). Supersedes the Knowledge Base primitive. See §3.7.

Function. A deployable bundle of Mission, Worker Definitions, 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 Worker Definitions, their Authority Grants, Escalation Routes, and any attached Compliance Profiles. See §6.7.

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

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

Driver. Implementation-defined logic by which a specific Worker realises decisions required by its Worker Definition. 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 realised result of executing an Intent — the delivered artefact(s) and measured score. Distinct from the terminal resolution kind (achieved | not-applicable | withdrawn | missed), which is the Intent’s state. 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 Worker Definitions’ 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 Worker Definition held by a human actor, distinguished from a Worker Definition. 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: — Worker Definition 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.