Skip to content
OWP

16. Extensibility and Versioning

16.1 Extension Points

The protocol provides extension points at the following loci:

  • New Signal kinds, Intent kinds, and Capability kinds MAY be defined by any party. Kind URIs are namespaced by authority; collisions are avoided through URI uniqueness.
  • New Compliance Profiles MAY be authored by any party. Profile URIs are similarly namespaced.
  • New Audit Envelope event kinds MAY be defined by implementations, provided they do not conflict with the kinds in §9.1.
  • Cost units MAY be extended; new units SHOULD be registered in a public registry to avoid collisions.

16.2 Function Versioning

Function versions are mandatory and explicit (§4.1.4). A Workforce instantiated from one Function version cannot be transparently migrated to another. Migration is a deployment operation requiring:

  • A new Workforce instantiation or an explicit version-upgrade operation supported by the runtime.
  • Decisions about open Intents: whether they continue under the prior version (run-out) or transition to the new version (re-bind).
  • Recording of the migration event in operational logs.

Function version migration is the mechanical realisation of Charter-amending Recalibration (§12.4). The decision layer that motivates and authorises a version migration — Evaluation evidence, Operator proposal, Architect co-signature — is specified in §12; this section specifies only the runtime mechanism by which an authorised migration is effected.

16.3 Protocol Versioning

This document describes the OWP-2 protocol family. Future major revisions of the protocol will be published under successor document family identifiers (OWP-3, OWP-4, …). Within a family, revisions are backwards-compatible at the wire and behavioural level wherever possible; breaking changes are reserved for new families.

A runtime MUST declare the protocol family and version it implements. A Function MUST declare the protocol family and minimum version it requires. The runtime MUST refuse to instantiate a Function whose required protocol exceeds the runtime’s implemented protocol.

16.4 Deprecation Policy

Specification elements deprecated in a published draft remain valid for a minimum of one further draft cycle. Deprecation notices MUST identify a planned removal version and a recommended alternative.