Skip to content
OWP-2

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

Identifiers in this protocol come in two families, and the distinction is load-bearing.

Per-instance identifiers are URIs. The following URI schemes are reserved:

  • worker: — Worker IDs (§3.1.2)
  • role: — Worker Definition IDs (§3.2.5)
  • intent: — Intent IDs (§3.4.4)
  • function: — Function IDs (§4.1.4)
  • workforce: — Workforce IDs (§4.2.2)
  • envelope: — Audit Envelope IDs (§9.1)

Per-instance identifiers are unique within the scope of their issuing authority.

Per-kind identifiers are wire-safe identifiers, not URIs. Signal kinds (§3.3.3), Intent kinds (§3.4.3) and Capability kinds (§3.5.2) match ^[A-Za-z0-9_-]{1,64}$, using _ for hierarchy and - for words. They are global names, and an implementation MUST NOT rely on dereferencing one: earlier drafts stated that a kind SHOULD resolve to a schema document, and no implementation was found to do so. Schema discovery, if required, belongs in its own mechanism rather than in the punctuation of an identifier.

The two families share prefixes — intent:0f3c… is an Intent ID and intent_underwriting_assess-property-risk_v1 is an Intent kind — so implementations MUST distinguish them structurally rather than by prefix. A _v<n> suffix marks a kind.

2.3.1 Field and value naming

Two conventions govern the schemas in this document. Both predate this statement of them; they are written down here because a convention that is only ever inferred is one that eventually drifts.

  • JSON field names are snake_case — measurement_criteria, futile_unchanged, parent_intent_id, under_specified.
  • Enumerated values are kebab-case — not-applicable, unmet-precondition, out-of-scope, cancelled-by-originator, driver-budget-exhausted.

The distinction carries meaning rather than taste: keys name structure, values are vocabulary. A reader encountering an unfamiliar token can tell from its punctuation alone which of the two it is.