Skip to content
OWP

About this document

Specification — Working Draft 0.2

Document IDOWP-2
Date2026-05-18
StatusWorking Draft. Not for production use.
EditorsMal Wanstall (Apophenic)
CategoryStandards Track

Status of This Document

This document is a working draft of the Open Worker Protocol. It is published for review and to ground implementation work conducted in parallel. The protocol surface defined here is subject to revision until the document reaches Final status. Implementations of this draft are not guaranteed to interoperate with implementations of subsequent drafts.

This specification is the open standard. It is vendor-neutral and binding on any conformant implementation. The Apophenic implementation of this specification is described in two companion documents in the same repository: docs/apophenic-workforce-product.md (what Apophenic Workforce is as a product) and docs/apophenic-workforce-architecture-hlsd.md (how it is built). Those documents are normative for Apophenic only; this specification governs every conformant runtime.

Comments on this document are invited. Errata, amendments, and superseding drafts will be published under the document family identifier OWP-2.

Distribution of this document is unlimited.

Changes Since Working Draft 0.1

This draft promotes Knowledge from a sub-category of Capability to a first-class protocol primitive, and partially closes the federation question for shared mutable state. Detailed motivation appears in ADR-W06 and ADR-W07 in the companion Apophenic Workforce repository.

Normative changes

  • New §3.7 Knowledge Base. A new primitive: the governed organisational asset (URI, version manifest, contribution policy, retention, ownership) that Knowledge Capability invocations resolve against. Knowledge Capabilities (§3.5.3) remain the invocation transport; Knowledge Base is the asset on the other end. Adds dual-track versioning (mutable current pointer + immutable content-hash-addressed versions) and single-writer federation semantics.
  • §3.2.4 Authority Grant. Adds a Knowledge Base authority axis alongside Capability authority. Roles now declare permitted Knowledge Bases and permitted Knowledge Capabilities independently; the runtime gates both axes on every retrieval.
  • §3.5.3 Capability Categories. Knowledge Capabilities recast from “invocations that retrieve organisational knowledge” to the invocation transport that resolves against a Knowledge Base (§3.7). Substantive lifecycle and governance language moved out of §3.5 and into §3.7.
  • §9.1 Event Types. Adds KnowledgeBaseRegistered, KnowledgeBaseVersionCreated, KnowledgeBaseCurrentPointerMoved, KnowledgeContributionProposed, KnowledgeContributionAccepted.
  • §9.2 Event Common Schema. CapabilityInvoked events that retrieve from a Knowledge Base MUST include knowledge_base_id, knowledge_base_version, and retrieved_content_hash. These fields are how the audit envelope binds a retrieval to a specific resolved content snapshot — re-fetching at the same (kb_id, version) is guaranteed bit-identical.
  • §13 Conformance. Knowledge Base primitive is Core (every conformant runtime). Cross-Workforce read federation is a new optional conformance class, Federated-Read, intermediate between Compliance-Capable and the (still-unclaimable) Federated class.

Non-normative changes

  • Appendix B.1.3 updated to cross-reference the new Knowledge Base primitive (§3.7) alongside the invocation transport (§3.5.3).
  • Appendix B.3 worked example updated to use the two-axis Role manifest (knowledge_bases + knowledge_capabilities) in place of the prior single knowledge_access block.
  • Appendix D.4 (Federation in detail) is now partially resolved: single-writer cross-Workforce read of governed state is specified in §3.7 and §13. Co-owned writes remain deferred.

Backwards-incompatibility notes

Implementations of Working Draft 0.1 are not guaranteed to interoperate with Working Draft 0.2. Specifically:

  • Role declarations using the prior single knowledge_access field continue to be valid input but MUST be translated by the runtime into the two-axis form before evaluation. Where translation is ambiguous (the prior field conflated Base identity with Capability operation), implementations SHOULD treat each entry as a Knowledge Base reference and infer the union of permitted Knowledge Capabilities from the Function’s registered Providers.
  • Audit events emitted under Working Draft 0.1 do not carry the new Knowledge Base reference fields. Implementations MAY emit them as null for replayed historical events; they MUST be present and non-null for any event emitted by a Working Draft 0.2 conformant runtime.

Abstract

This document specifies the Open Worker Protocol (OWP). The protocol defines the wire-level and behavioural primitives required to deploy non-human knowledge workers as accountable members of an organisation.

Knowledge work has historically been governed by organisational primitives developed over centuries: identity, role, authority, escalation, audit, and accountability. These primitives have no direct equivalents in contemporary autonomous systems, which are typically deployed without stable identity, defined role, bounded authority, or auditable provenance. This protocol specifies those equivalents.

The protocol defines six primitives — Worker, Role, Signal, Intent, Capability, and Audit Envelope — together with two deployment artefacts (Function, Workforce) and three cross-cutting requirements (provenance, cost, and charter binding). These compose to express the full set of organisational constructs by which knowledge work is governed.

The protocol is vendor-neutral: it specifies what a worker is and how it must behave, not which model, framework, runtime, or vendor is used to realise it. The protocol is open: implementations may be hosted, self-hosted, or embedded, and the conformance criteria are testable against any implementation regardless of underlying technology.