Skip to content
OWP

4. Deployment Artefacts

The primitives in §3 are realised in deployment through two artefacts: Function and Workforce. These are not themselves primitive; they are the package and the runtime instantiation, respectively.

4.1 Function

4.1.1 Definition

A Function is a deployable bundle that specifies a coherent unit of organisational work. It is the unit of authoring, distribution, versioning, and deployment.

A Function MUST contain:

  • A Mission (§4.1.2).
  • A set of Role declarations (§3.2).
  • A set of Signal subscription declarations, scoped to the Function (§4.1.3).
  • A set of seeded Intents — the Intents the runtime should create at the moment the Function is deployed (§4.1.4).
  • A Charter (§6.7).
  • Any attached Compliance Profiles (§11).
  • Function metadata: Function ID, version, author, creation date, signing key.

A Function is a static artefact. It does not have running state. Running state belongs to the Workforce instantiated from the Function.

4.1.2 Mission

The Mission is the workforce-level statement of purpose. It is to a Function what a Standing Intent is to a Role, but at a higher level.

The Mission MUST be human-readable and SHOULD be machine-readable. It is consumed by Architects, Reviewers, and Resolvers to understand the Function’s intent and is referenced (through its identifier) by the Audit Envelope when describing the originating context of a top-level Intent.

4.1.3 Function-Scoped Signal Subscriptions

Signal subscriptions declared at the Function level are subscriptions for Signal Sources that the Function as a whole depends on. The runtime MUST verify, before instantiating a Workforce from the Function, that the requested Signal Sources are available.

Per-Role Signal subscriptions are declared in the Role (§3.2.3). The Function-level subscriptions ensure the prerequisites; the Role-level subscriptions distribute the deliveries.

4.1.4 Function ID

A Function ID MUST be a URI of the form:

function:<authority>:<name>/v<n>

Versioning is mandatory. Two Functions with the same name and different versions are distinct artefacts; a Workforce instantiated from one cannot be transparently migrated to another. Migration semantics are addressed in §16.

4.1.5 Function Signing

A Function MUST be signed by its authoring authority. The signature covers:

  • The Mission.
  • All Role declarations.
  • All Signal subscription declarations.
  • All seeded Intents.
  • The Charter (excluding any per-Workforce overrides).
  • All attached Compliance Profile references.

A runtime MUST verify the Function signature before instantiating a Workforce.

4.2 Workforce

4.2.1 Definition

A Workforce is the running instantiation of one or more Functions. It is a runtime entity comprising:

  • A set of actual Workers, each bound to exactly one Role drawn from the deployed Functions (§3.2.1).
  • A set of open Intents being pursued.
  • A set of open Audit Envelopes.
  • The runtime services required to mediate Capability invocations, route Signals, enforce authority, and sign events.
  • Configuration overrides, where the Function permits them, applied per-Workforce (e.g. customer assignment, jurisdiction).

A Workforce is the unit of running organisational work. It corresponds, in human terms, to a deployed team or department.

4.2.2 Workforce ID

A Workforce ID MUST be a URI of the form:

workforce:<authority>:<name>

The <name> segment SHOULD be human-readable and chosen at Workforce creation time by the Architect or Operator deploying the Workforce. Implementations MUST NOT rely on parsing <name> for semantic meaning; it is intended as an aid to operators reading logs, audit trails, and identifiers in surfaces where the full Workforce ID appears. Auto-generated <name> segments (timestamps, opaque hashes) are conformant but discouraged.

Workforce IDs are stable. A Workforce that is shut down and re-instantiated under new Function versions retains its Workforce ID; the version change is recorded in the Workforce’s configuration history rather than in a new identifier.

4.2.3 Workforce Metadata

Beyond the Workforce ID, implementations MAY carry the following optional metadata fields:

  • display_name — a human-readable name distinct from the URI <name> segment. Useful where the URI <name> is constrained (e.g. URL-safe characters only) but the operating organisation wants a richer label (Unicode, spaces, branding).
  • description — free-form descriptive text explaining the Workforce’s purpose, scope, or operating context.
  • created_at, created_by — provenance of the Workforce’s creation.

These fields are out-of-protocol metadata. The protocol does not specify their wire shape and conforming implementations MUST NOT depend on their presence for protocol-level operations. The Workforce ID remains the canonical identifier for all protocol-level references (Worker IDs, audit envelopes, federation links, etc.).

4.2.4 Worker Instantiation

A Workforce instantiates Workers in conformance with its deployed Functions. Workers may be instantiated:

  • At deployment time, for Roles whose Standing Intent requires immediate presence (e.g. a per-customer coverage Role over a fixed customer base).
  • On demand, in response to Signals or Intents that require a Worker of a particular Role.

Worker instantiation MUST allocate a Worker ID, a cryptographic identity, and persistent storage, and MUST register the Worker with the runtime such that the Worker becomes a recognised actor.

Worker decommissioning is the symmetric operation. A decommissioned Worker’s Worker ID MUST NOT be reused; its history MUST be retained per the applicable retention horizon.

4.2.5 Human Role Bindings

§7 specifies the authorities each Human Role carries. Those authorities are exercised by specific human principals, so a runtime MUST maintain explicit bindings between principals and Human Roles within each Workforce, and MUST consult those bindings whenever a Human Role authority is invoked.

4.2.5.1 Binding Artefact

A Human Role Binding is a tuple:

(workforce_id, human_role, principal_id, function_id?, bound_at, bound_by, unbound_at?)
  • workforce_id: the Workforce the binding applies to. Bindings are Workforce-scoped; the same principal MAY be independently bound to the same Role in multiple Workforces.
  • human_role: one of architect, operator, reviewer, resolver.
  • principal_id: the human principal being bound, identified by the principal URI scheme (§2.4).
  • function_id (optional): narrows the binding to a single Function within the Workforce. When omitted the binding applies Workforce-wide — i.e. to every Function currently deployed and to every Function deployed later.
  • bound_at: when the binding was established.
  • bound_by: the principal who established it. For initial bindings this is the Architect who created the Workforce.
  • unbound_at: when set, the binding is no longer active. Bindings MUST NOT be deleted; unbinding sets this timestamp so the history stays auditable.
4.2.5.2 Lifecycle

Bindings are established and revoked through explicit, audited operations:

  • Bind. An authorised principal establishes a new binding. The runtime MUST emit a HumanRoleBound event into the Workforce’s governance envelope with the full tuple.
  • Unbind. An authorised principal revokes an existing binding. The runtime MUST emit a HumanRoleUnbound event into the same envelope, and MUST refuse any subsequent attempt by the unbound principal to exercise the Role’s authority in this Workforce.

The authority to bind and unbind Human Roles is itself a Workforce governance concern. The defaults: the first Architect binding is established by the principal that created the Workforce (typically a deploy-time bootstrap path); subsequent bindings require an Architect of the Workforce; an Architect MAY unbind themselves only while at least one other active Architect binding remains, to keep the governance authority from being orphaned. Implementations MAY add stricter rules — multi-party approval, mandatory waiting periods, and similar — as deployment policy.

4.2.5.3 Resolution and Enforcement

The runtime MUST be able to resolve, for any (workforce_id, human_role, principal_id, function_id?) query, whether an active binding exists. This resolution MUST run synchronously at every point a Human Role authority is invoked:

  • §4.1.5 Function signing: the signing principal MUST be bound as an Architect for the Workforce into which the Function is being deployed (or hold Authority via federation per §16).
  • §6.4 Outcome refusal: the refusing principal MUST be bound as a Reviewer for the Workforce — and, if the binding is Function-narrowed, for the Function the Outcome belongs to.
  • §12 Evaluation commissioning: the commissioning principal MUST be bound as an Operator for the Workforce.
  • §12.4 Recalibration signing: the proposing principal MUST be bound as an Operator for the Workforce, and (for charter-amending targets) the co-signing principal MUST be bound as an Architect for the same Workforce.

Signatures from principals lacking the required binding MUST be refused, and the runtime MUST emit an authority-violation event in the same shape §6.7 specifies for Worker authority violations.

4.2.5.4 Multi-Binding

§7 allows a single human principal to concurrently hold multiple Human Roles. The binding artefact handles this directly: each (workforce_id, human_role, principal_id, function_id?) combination is a distinct binding. A principal bound as both Architect and Operator for the same Workforce has two binding rows and exercises either authority independently.

The runtime MUST NOT silently collapse multi-role principals into a single binding. The audit trail for who authorised what under which Role depends on each Role-binding being explicit.