3. Primitives

This section specifies the six primitives of the protocol. The primitives are orthogonal: each is irreducible and is not derivable from the others. Constructs commonly required in practice — including procedure, dispatch, escalation, outcome, workflow, and coordination — are derived from the primitives by composition and are not themselves primitive. Where this document treats a derived construct in detail (e.g. Dispatch in §6.4), it does so for clarity, not to elevate the construct to primitive status.

3.1 Worker

3.1.1 Definition

A Worker is an organisational actor with stable identity. A Worker MUST possess:

• A unique identifier (the Worker ID), as specified in §3.1.2.
• A cryptographic identity, used for signing actions and audit events, as specified in §3.1.4.
• Exactly one assigned Role, as specified in §3.2. (Multi-role binding does not apply to Workers; it applies only to human principals per §7.)
• A persistent history of received Signals, accepted and generated Intents, invoked Capabilities, and emitted events, as specified in §3.1.6.

A Worker is the unit of identity and accountability in the protocol. A Worker persists across runs, sessions, and Capability invocations. A Worker is not a function call. A Worker is not a session. A Worker is not a process. A Worker is an entity that exists in the organisation in the same sense that a human employee exists in the organisation.

3.1.2 Worker ID

A Worker ID MUST be a URI of the form:

worker:<authority>:<workforce-id>:<local-id>

where:

• <authority> is a registry-allocated identifier for the organisation operating the Worker. The format of the authority field is governed by an authority registry defined in a companion document; for the purposes of this draft, an authority MAY be any DNS name controlled by the organisation.
• <workforce-id> is the identifier of the Workforce in which the Worker resides, unique within the authority.
• <local-id> is unique within the Workforce. Local IDs SHOULD be opaque; implementations MUST NOT rely on parsing local IDs for semantic meaning.

A Worker ID MUST be stable for the life of the Worker. A Worker ID MUST NOT be reassigned to a different cryptographic identity once issued. If a Worker is decommissioned, its Worker ID is retired; a successor Worker, even one fulfilling the same Role, MUST receive a new Worker ID.

Stable Worker IDs are the basis of organisational continuity. Reuse of Worker IDs across distinct cryptographic identities would render audit envelopes ambiguous and is therefore prohibited.

3.1.3 Worker Driver

The protocol does not specify how a Worker realises its decisions. The implementation logic by which a Worker decides whether to accept an Intent, which Capabilities to invoke, when to dispatch sub-Intents, when to escalate, and when to resolve is termed the Worker Driver.

A Driver MAY be:

• A language-model invocation against an LLM Capability Provider, with system context derived from the Worker’s Role.
• Deterministic code.
• A human-in-the-loop process realised through a human-channel Capability Provider.
• Any composition of the above.

The Driver is not directly observable to the protocol. The protocol observes the Driver only through the Worker’s outbox: the Capability invocations, Dispatches, Escalations, and Resolutions the Worker produces.

The Driver MUST conform to the Worker’s Role at all times. The runtime MUST refuse outbox actions that exceed the Role’s Authority Grant; see §6.7. The protocol thereby achieves vendor neutrality: any Driver may be used so long as its outbox is conformant.

3.1.4 Worker Cryptographic Identity

A Worker MUST hold a cryptographic identity. The identity consists of an asymmetric keypair. The public key is bound to the Worker ID through registration with the runtime. The private key, or a reference thereto suitable for signing, MUST be held in a manner conformant with §14 (Security Considerations).

The Worker’s cryptographic identity is used to sign:

• Outbox actions (Capability invocations, Dispatches, Escalations, Resolutions).
• Events emitted to the Audit Envelope.

Implementations MUST use a signature algorithm appropriate for non-repudiation. RECOMMENDED algorithms are listed in §14.2.

Key rotation is permitted under the conditions specified in §14.3. A Worker MAY hold multiple key versions concurrently during a rotation window.

3.1.5 Worker State

A Worker has a persistent state that MUST include, at minimum:

• The Worker’s Worker ID and cryptographic identity.
• The Worker’s assigned Role (a single Role; see §3.2.1).
• The Worker’s currently-open Intents (those accepted but not yet resolved).
• A reference to the Worker’s history.
• Any per-Worker configuration declared by the Role (see §3.2).

Worker state MUST persist across runtime restarts. A Worker that loses state is no longer the same Worker; the runtime MUST treat such a loss as Worker decommissioning and require a new Worker to be instantiated under a new Worker ID. The protocol of decommissioning, including handover of open Intents, history retention, and key revocation, is specified in §12.5.

3.1.6 Worker History

A Worker’s history is the ordered record of Signals received, Intents accepted and generated, Capabilities invoked, Dispatches and Escalations issued, and Outcomes resolved.

The history MUST be retrievable by:

• The Worker (so that prior context informs future decisions).
• The runtime (so that audit envelopes can be reconstructed and so that authority enforcement can refer to recent activity).
• Human Roles holding appropriate authority — at minimum, Reviewers of the Function in which the Worker resides — through a runtime-mediated query interface.

The retention horizon for Worker history is implementation-defined unless constrained by an attached Compliance Profile (§11). Implementations SHOULD make retention horizons explicit and reviewable.

A Worker’s history is the basis of organisational memory. The protocol does not prescribe how the Worker’s Driver consumes history; that is a Driver concern. The protocol prescribes that history MUST be available to be consumed.

3.2 Role

3.2.1 Definition

A Role is the charter definition for a class of work. A Role specifies, normatively for any Worker holding it:

• A Standing Intent (§3.2.2).
• A set of Signal subscriptions (§3.2.3).
• An Authority Grant (§3.2.4).
• An Intent Grammar (§3.2.5).
• A set of Escalation Routes (§3.2.6).

A Role is a class. A Worker is an instance of exactly one Role at any moment. Multiple Workers MAY hold the same Role concurrently — typically with distinct deployment contexts such as per-customer or per-region assignment — and a Role is not in itself a singleton; but a single Worker MUST NOT be bound to more than one Role at the same time.

The single-Role binding rule is specific to Workers and is motivated by audit clarity, authority unambiguity, and lifecycle simplicity. Where a use case appears to require an actor that fills two organisational positions, the conformant pattern is two Workers — one per Role — composing through Intent dispatch, rather than one Worker with multiple Roles. Multi-role binding remains permissible at the Human Role layer (§7), where a single human principal MAY concurrently hold combinations such as Architect and Reviewer; this is a property of human-actor identity, not of Worker identity.

A Worker’s Role binding MAY change over the Worker’s lifetime (e.g. through Recalibration, §12.4), but at any single moment the binding is to one Role and one Role only. Charter version changes within the same Role do not constitute Role rebinding.

A Role MUST have a Role ID of the form:

role:<function-id>:<role-name>

where <function-id> is the Function in which the Role is declared and <role-name> is unique within the Function.

3.2.2 Standing Intent

The Standing Intent is a structured statement of the Role’s reason to exist. It is consumed by the Worker’s Driver to inform Intent generation: a Worker with Standing Intent “maintain coverage of this customer relationship” generates outreach Intents in response to relevant Signals; a Worker with Standing Intent “screen all outbound advice for suitability” generates review Intents in response to advice-emission Signals.

A Standing Intent declaration MUST include:

• A human-readable statement of the objective. The statement MUST be sufficient for an Architect to author and an Reviewer to review.
• A machine-readable structure sufficient for a Driver to interpret. The structure SHOULD be expressible as a typed objective with optional parameters; the protocol does not prescribe a single objective grammar.

Example (non-normative):

{
  "human_statement": "Maintain coverage of the relationship for the assigned customer. Surface material risks, opportunities, and life-events to the human Relationship Manager. Do not initiate customer contact directly.",
  "objective": {
    "kind": "intent:owp:coverage:maintain-relationship/v1",
    "parameters": {
      "customer_id": "customer:bank-au:c-1029384",
      "review_cadence": "P30D",
      "material_threshold_aud": 50000
    }
  }
}

The Standing Intent is bound to the Role, not to the Worker. A Worker holding the Role inherits the Standing Intent at the moment of binding and is released from it at the moment of unbinding.

3.2.3 Signal Subscriptions

A Role MUST declare the Signal kinds it consumes. The declaration MAY be a kind-by-kind enumeration or a pattern over Signal kind URIs. The runtime MUST deliver Signals of subscribed kinds, and only of subscribed kinds, to Workers holding the Role.

Subscription declarations MAY include filters on Signal payloads. A filter is a runtime-evaluable predicate that, when false, prevents delivery of the Signal to the Worker. Filters allow Roles to subscribe with finer granularity than kind alone — for example, a “Sector Analyst (Construction)” Role may subscribe to all market-news Signals filtered to the construction sector.

The subscription declaration is part of the Role’s charter and is enforced by the runtime. A Worker MUST NOT receive Signals outside its Role’s subscriptions, regardless of any internal request by the Worker’s Driver.

3.2.4 Authority Grant

The Authority Grant is the specification of which actions the Role permits. It MUST address, at minimum:

• Capability authority. Which Capability kinds the Worker may invoke. MAY be expressed as an enumeration or a pattern. MAY include parameter constraints (e.g. “may invoke capability:owp:llm/v1 but only with model parameter class:reasoning-medium or below”).
• Knowledge Base authority. Which Knowledge Bases (§3.7) the Worker may read, and where granted, which Bases the Worker may propose contributions to. MAY be expressed as an enumeration or a pattern over Knowledge Base URIs. The Knowledge Base axis is orthogonal to the Capability axis: a Worker MUST hold both Knowledge Capability authority and Knowledge Base authority to retrieve. Either axis MAY be tightened independently (e.g. “may invoke capability:knowledge:vector-query and capability:knowledge:policy-lookup against knowledge-base:bank-au:policy:* but only capability:knowledge:policy-lookup against knowledge-base:bank-au:regulatory:*”). Authority that is not explicitly granted is implicitly denied on both axes. The runtime MUST refuse retrievals where either axis denies, and emit an authority-violation event.
• Dispatch authority. Which Roles the Worker may dispatch Intents to, and which Intent kinds it may dispatch. A Worker MUST NOT dispatch an Intent kind to a Role that does not declare that kind in its acceptable Intent grammar (§3.2.5).
• Cost bounds. The maximum cost the Worker may incur in pursuing a single Intent, and the maximum cumulative cost over a declared window. Costs are denominated per §10.
• Decision scope. The categories of decisions the Worker may take unilaterally (e.g. “MAY resolve Intents of kind X with Outcome achieved without escalation if value is below AUD 50,000”). Decisions outside scope MUST be escalated.
• Temporal bounds. Maximum elapsed time the Worker may pursue a single Intent before escalation is REQUIRED.
• Recalibration authority. Whether the Worker may sign Evaluations or Recalibrations (§12). Default: denied. This authority is reserved for Operator Roles (§7.4) and is rarely granted to non-human Workers; where it is granted, the granted scope MUST be explicitly bounded.
• Self-decommissioning authority. Whether the Worker may initiate its own decommissioning per §12.5.1, and under what conditions (e.g. on detecting incoherence in its own state, on prolonged inability to make progress). Default: denied. Where granted, the runtime MUST treat self-decommissioning as a Recalibration with target worker-decommission signed by the Worker itself, subject to the same handover requirements as Operator-initiated decommissioning. This closes Open Question D.8.

The Authority Grant is enforced by the runtime at the point of every outbox action; see §6.7. Authority that is not explicitly granted is implicitly denied. A Worker MUST NOT take any action that exceeds its Authority Grant; the runtime MUST refuse such actions and emit an authority-violation event to the Audit Envelope.

The Authority Grant is the principal mechanism by which the charter model is enforced. Its richness directly determines the safety properties of the deployed Workforce.

3.2.5 Intent Grammar

A Role MUST declare:

• The Intent kinds it can generate (i.e. dispatch to other Roles or pursue itself).
• The Intent kinds it can accept (i.e. receive via Dispatch).

These two declarations together form the Role’s Intent Grammar.

The Intent Grammar is enforced bidirectionally:

• The runtime MUST refuse any Dispatch in which the source Worker’s Role does not generate the Intent kind, or in which the target Worker’s Role does not accept the Intent kind.
• Where multiple Roles match an unbound Dispatch (one with no specific target Worker), the runtime MUST select among Roles whose Intent Grammar accepts the kind.

The Intent Grammar’s structure makes the Workforce’s possible communication patterns statically inspectable. Architects MAY analyse a Function’s Roles to determine, prior to deployment, which Intents can flow between which Roles. Reviewers MAY inspect the same to verify regulatory or organisational constraints.

3.2.6 Escalation Routes

A Role MUST declare its Escalation Routes: the Roles (Worker or Human) to which a Worker holding this Role MAY escalate, and under what conditions.

An Escalation Route MUST specify:

• The target Role (a Worker Role with strictly greater authority on the relevant dimension, or a Human Role).
• The conditions under which the route is taken: typically authority limits exceeded, decision scope exceeded, time bounds exceeded, or Worker discretion.
• Whether the route is REQUIRED or DISCRETIONARY for each condition.

The runtime MUST treat an Escalation Route declaration as an exclusive list. A Worker MUST NOT escalate to a Role not declared in the Escalation Routes of its Role. This prevents accidental authority leakage.

A Role with no Escalation Routes is permissible only for terminal Roles — typically, Human Roles representing final decision-makers whose authority has no further upward route within the Workforce.

3.3 Signal

3.3.1 Definition

A Signal is a typed stimulus delivered to a Worker. Signals are the primary mechanism by which the Workforce becomes aware of the world and of itself.

3.3.2 Signal Kinds

The protocol distinguishes four kinds of Signal:

• External Signals originate outside the Workforce. They are produced by Capability Providers categorised as Signal Sources (§3.3.4) and represent events in the world: market data, customer interactions, news, regulatory announcements, partner events, sensor readings, and so forth.
• Internal Signals originate within the Workforce. They are produced by Workers as a side-effect of their actions, or as explicit publications. They represent organisational events: an Intent resolved, a Worker decommissioned, a Compliance Profile attached, an Outcome refused.
• Temporal Signals originate from the runtime’s temporal service. They represent time-based stimuli: deadlines, anniversaries, periodic reviews, scheduled checks. Workers subscribing to temporal Signals declare the temporal expressions they care about (cron-like expressions, durations relative to other events, calendar dates).
• Inferential Signals originate from Workers whose Role is to derive higher-order Signals from lower-order ones. An inferential Signal is functionally indistinguishable from an internal Signal at the point of delivery; it is distinguished by intent — its Worker’s Role exists to produce it.

All four kinds are delivered through a uniform interface specified in §6.1.

3.3.3 Signal Kind URIs

A Signal kind MUST be identified by a URI. The URI MUST resolve, when dereferenced, to a schema document describing the structure of payloads of that kind. Implementations are NOT REQUIRED to dereference the URI at runtime, but MUST treat it as the authoritative identifier for the kind.

Recommended URI form (non-normative):

signal:<authority>:<domain>:<name>/v<n>

For example:

• signal:bank-au:transactions:large-debit/v1
• signal:apophenic:hr:onboarding-complete/v2
• signal:owp:temporal:deadline-approaching/v1

3.3.4 Signal Sources

External Signals are produced by Capability Providers in the role of Signal Source. A Signal Source Provider MUST declare the Signal kinds it emits and SHOULD describe its emission semantics (frequency, latency, ordering, idempotency).

The protocol does not specify how Signal Sources observe the world. It specifies only that emitted Signals MUST conform to the declared kinds and MUST carry the metadata required by §3.3.5.

A Signal Source is architecturally distinct from an invocable Capability Provider (Model, Tool, Knowledge, or Human per §3.5.3). The two share the trust boundary defined in §8 — registration, mutual authentication, cost reporting, deregistration — but their data flow direction, lifecycle, and runtime semantics differ. A Signal Source emits Signals that the runtime routes to subscribed Workers (push, governed by Role subscriptions per §3.2.3 and §6.1). An invocable Capability Provider serves request-response invocations made by Workers in pursuit of an Intent (pull, governed by Authority Grant per §3.2.4 and §6.7). Implementations SHOULD treat the Signal domain (subscription, routing, filtering, delivery) and the Capability invocation domain (authority enforcement, invocation gateway, response validation) as separate architectural subsystems even where they share the Provider trust boundary.

3.3.5 Signal Structure

A Signal is a structured object containing, at minimum:

• A Signal ID, unique within the runtime.
• A Signal kind URI.
• An emission timestamp (logical and wall-clock).
• A source identifier (the Capability Provider, Worker, or runtime service that emitted the Signal).
• A payload, conformant with the schema referenced by the kind URI.
• A signature by the source, where the source is capable of signing (Capability Providers and Workers MUST sign; runtime services MAY sign with the runtime’s identity).

Example (non-normative):

{
  "signal_id": "sig:01HXXJ3F2K8N0QRSTUV001",
  "kind": "signal:bank-au:credit:debtor-bankruptcy/v1",
  "emitted_at": {
    "wallclock": "2026-05-07T03:14:09.812Z",
    "logical": 84729183
  },
  "source": "provider:bank-au:asic-feed",
  "payload": {
    "debtor_abn": "12 345 678 901",
    "creditor_relationships": ["customer:bank-au:c-1029384"],
    "estimated_exposure_aud": 1820000,
    "filing_reference": "ASIC-2026-NSW-184729"
  },
  "signature": "..."
}

3.3.6 Signal Delivery

Signal delivery is governed by Role subscriptions (§3.2.3) and by the runtime delivery semantics specified in §6.1. The protocol does not require any particular delivery mechanism (push, pull, queue, stream); it specifies only the abstract guarantees that any conforming delivery mechanism MUST provide.

3.4 Intent

3.4.1 Definition

An Intent is a typed desired outcome being pursued. It is the unit of work in the protocol. Where procedural systems decompose work into “steps,” this protocol decomposes work into nested Intents: a top-level Intent is pursued by a Worker, who may dispatch sub-Intents to other Workers, who may in turn dispatch further sub-Intents.

An Intent is the verb of the protocol. A Function specifies what kinds of Intent its Roles can generate and accept. A Workforce, at any moment, is a set of open Intents being pursued by Workers. The history of a Workforce is the closed set of resolved Intents.

3.4.2 Intent Lifecycle

An Intent has a lifecycle with the following states:

• Open. The Intent has been generated but not yet accepted by any Worker.
• Accepted. The Intent has been accepted by a specific Worker; that Worker is now pursuing it.
• In-progress. The Intent is actively being pursued. This state is a refinement of Accepted and MAY be omitted; an Intent moves through it implicitly.
• Escalated. The Intent has been escalated; a different Worker or Human Role has assumed responsibility.
• Resolved. The Intent has reached a terminal state. The Outcome (§6.6) is one of: achieved, refused, abandoned. Escalation to terminal resolution by another Worker results in achieved or refused for the original Intent; the escalating Worker is released.

Transitions between states MUST be recorded in the Audit Envelope (§9). The runtime MUST refuse transitions not permitted by the lifecycle.

3.4.3 Intent Kind URIs

An Intent kind MUST be identified by a URI, in the same scheme as Signal kinds:

intent:<authority>:<domain>:<name>/v<n>

The URI MUST resolve to a schema document describing the structure of Intent payloads of that kind. Intent kinds are referenced by Roles in their Intent Grammar (§3.2.5).

3.4.4 Intent Structure

An Intent is a structured object containing, at minimum:

• An Intent ID, unique within the runtime.
• An Intent kind URI.
• A creation timestamp.
• A creating party — the Worker, Human Role, or Capability Provider that generated the Intent.
• A target — the Worker ID or Role to which the Intent is addressed. The target MAY be unbound; an unbound Intent is dispatched to any Worker holding a matching Role with capacity (see §6.4).
• A payload, conformant with the schema referenced by the kind URI.
• A provenance chain — the prior Intents (if any) and Signals that gave rise to this Intent.
• An authority binding — the Authority Grant under which the Intent was generated (the Role and clause that authorise its creation).
• Bounds — cost ceiling, deadline, decision scope. Bounds inherit from the generating Worker’s Authority Grant unless the generator explicitly tightens them.
• A current state (Open, Accepted, etc.).
• A resolution slot, populated when the Intent reaches a terminal state, containing the Outcome record (§6.6).

Example (non-normative, a fragment showing only structural fields):

{
  "intent_id": "int:01HXXJ3GR8N7N0QRSTUV001",
  "kind": "intent:bank-au:coverage:propose-customer-outreach/v1",
  "created_at": "2026-05-07T03:14:11.044Z",
  "created_by": "worker:bank-au:wf-coverage-prod:rm-c1029384",
  "target_role": "role:function:bank-au:coverage:senior-relationship-manager",
  "payload": {
    "customer_id": "customer:bank-au:c-1029384",
    "trigger_summary": "Material counterparty bankruptcy. Estimated exposure AUD 1.82M.",
    "proposed_action": "schedule-call",
    "proposed_talking_points": [
      "Acknowledge the supplier collapse...",
      "Working-capital facility option..."
    ]
  },
  "provenance": {
    "originating_signal": "sig:01HXXJ3F2K8N0QRSTUV001",
    "parent_intent": null
  },
  "authority": {
    "role": "role:function:bank-au:coverage:relationship-worker",
    "grant_clause": "may-generate.intent.coverage.propose-customer-outreach"
  },
  "bounds": {
    "cost_ceiling_aud": 5.00,
    "deadline": "2026-05-07T07:00:00Z",
    "decision_scope": "propose-only"
  },
  "state": "open",
  "resolution": null
}

3.4.5 Intent Provenance

Every Intent MUST record its provenance: the originating Signal (if any) and the parent Intent (if any). An Intent may be:

• Signal-originated: generated by a Worker in response to a subscribed Signal. The originating Signal ID MUST be recorded.
• Intent-originated: generated by a Worker as a sub-Intent of an Intent it is pursuing. The parent Intent ID MUST be recorded.
• Standing-originated: generated by a Worker from its Standing Intent without a specific Signal trigger (e.g. a periodic review). The originating clause of the Standing Intent MUST be recorded.
• Externally-originated: generated outside the Workforce (e.g. by a Human Role through the human-channel Capability) and accepted into the Workforce. The originating party and channel MUST be recorded.

Provenance enables post-hoc reconstruction of any chain of work in the Workforce. The Audit Envelope (§9) is rooted at the originating Intent of a chain and contains all derived Intents.

3.5 Capability

3.5.1 Definition

A Capability is a vendor-neutral invocation surface. A Worker invokes a Capability to make progress on an Intent. The protocol observes Workers exclusively through their Capability invocations and Dispatches.

Capabilities are stateless from the protocol’s perspective. A Capability invocation has inputs and outputs; it does not have persistent identity. (A Capability Provider may have persistent state — a database, a model, a credential store — but the Capability itself, the invocation, does not.)

This statelessness is the principal distinction between a Capability and a Worker. A Worker is a who; a Capability is a what.

3.5.2 Capability Kinds

A Capability kind is identified by a URI:

capability:<authority>:<domain>:<name>/v<n>

The URI MUST resolve to a schema document describing:

• The structure of the invocation request.
• The structure of the invocation response.
• The Cost units the Capability emits (§10).
• The Capability’s invocation semantics (synchronous, asynchronous, streaming).

Examples (non-normative):

• capability:owp:llm:chat-completion/v1
• capability:owp:human:notify-and-await-decision/v1
• capability:apophenic:knowledge:retrieve-policy-document/v1
• capability:owp:tool:invoke-mcp/v1

3.5.3 Capability Categories

For the purposes of this protocol, Capabilities fall into four categories. The categories are descriptive, not exclusive; a Capability may meaningfully belong to more than one. The categories influence the requirements §8 places on Capability Providers.

• Model Capabilities. Invocations of language, vision, or other ML models. Examples: chat completion, structured generation, embedding.
• Tool Capabilities. Invocations of deterministic external systems. Examples: HTTP requests, database queries, file operations, MCP tools.
• Human Capabilities. Invocations that route work to a human via the human’s existing channels. Examples: Slack message-and-await-reply, email-with-form, Linear-issue-and-await-resolution.
• Knowledge Capabilities. Invocations that retrieve from a Knowledge Base (§3.7). Examples: vector query, document retrieval, policy lookup, exemplar lookup. The Capability defines the operation (the shape of the query and the shape of the response); the Knowledge Base it resolves against defines the asset (the body of governed content). Both axes are required: a Worker MUST hold both Knowledge Capability authority and Knowledge Base authority under its Authority Grant (§3.2.4). A Knowledge Capability invocation MUST identify the target Knowledge Base in its parameters, and the Provider MUST return the resolved Base version and content hash in its response per §3.7.

Signal Sources (§3.3.4) emit Signals into the runtime rather than serving invocations. They share the Provider trust boundary defined in §8 with the four invocable Capability categories above but are architecturally distinct: Signals are pushed to Workers via the Signal Router (§6.1) per Role subscriptions, whereas Capabilities are invoked by Workers in pursuit of an Intent (§6.7). Implementations SHOULD treat Signal Sources and invocable Capability Providers as separate architectural surfaces, sharing only the Provider trust primitive.

3.5.4 Capability Invocation

A Worker invokes a Capability by submitting an invocation request to the runtime. The request specifies:

• The Capability kind.
• The Capability Provider (where multiple Providers expose the same kind).
• The invocation parameters, conformant with the kind’s schema.
• The Intent under which the invocation is authorised.
• The signature of the invoking Worker.

The runtime MUST verify, before forwarding the invocation:

• The Worker’s Role permits the Capability kind under its Authority Grant.
• The cost of the invocation, where bounded by the Provider’s pricing, fits within the Intent’s bounds.
• The invocation parameters validate against the kind schema.

If verification succeeds, the runtime forwards the invocation to the Provider, captures the response, emits a CapabilityInvoked event with embedded Cost Record to the Audit Envelope, and returns the response to the Worker. If verification fails, the runtime refuses the invocation and emits an authority-violation event.

3.6 Audit Envelope

3.6.1 Definition

The Audit Envelope is an append-only, signed, ordered record of every event tied to a root Intent. It is rooted at the moment a top-level Intent is generated and grows as the Workforce pursues that Intent — through sub-Intents, Capability invocations, Dispatches, Escalations, and Outcomes.

The Audit Envelope is the protocol’s mechanism for tying organisational outcomes to organisational provenance. Every action a Worker takes, every cost it incurs, every Capability it invokes, and every decision it makes is captured in the Envelope of the Intent under which it acted.

3.6.2 Audit Envelope Identity and Scope

An Audit Envelope is identified by a URI:

envelope:<workforce-id>:<envelope-id>

A Workforce MUST issue a new Audit Envelope for every top-level Intent it accepts — that is, for every Intent whose provenance does not point to a parent Intent within the Workforce. Sub-Intents derived from a top-level Intent share its Envelope; they do not have their own.

Externally-originated Intents (originating from a Human Role, a Signal Source acting as an Intent originator, or a federated Workforce) initiate new Envelopes upon acceptance into the Workforce.

3.6.3 Audit Envelope Contents

An Audit Envelope MUST contain, in append-only order, all events specified in §9.1 that occur in pursuit of its root Intent. The full Envelope structure and signing is specified in §9.

3.6.4 Audit Envelope Closure

An Audit Envelope is open while its root Intent is in any non-terminal state. It is closed when the root Intent reaches a terminal state.

Once closed, an Audit Envelope is immutable. The runtime MUST seal the Envelope by computing and signing its final Merkle root and recording the closure timestamp. Subsequent events related to the Envelope’s subject matter (e.g. a customer query about the same case) belong to a new Envelope, with a provenance reference to the closed one.

3.7 Knowledge Base

3.7.1 Definition

A Knowledge Base is a governed organisational asset against which Knowledge Capability invocations (§3.5.3) resolve. A Knowledge Base is the body of policies, regulations, product specifications, exemplars, reference data, market reports, or other curated content a Role draws on to perform its work.

A Knowledge Base is a primitive, not a parameter on a Capability invocation. Its lifecycle — creation, versioning, contribution, retirement — is governed by the protocol; its content is identifiable by URI, addressable by version, and verifiable by content hash. The Audit Envelope MUST reference Knowledge Bases by (knowledge_base_id, version, content_hash) on every retrieval (§9.2); a regulator or Reviewer asking “what knowledge informed this decision?” MUST receive a deterministic, content-addressed answer.

A Knowledge Base is distinguished from a Capability by its statefulness and from a Worker by its passivity. A Capability invocation is stateless; a Knowledge Base is the state the Capability reads. A Worker is an actor; a Knowledge Base is an asset acted upon. The Provider trust boundary (§8) applies to Knowledge Bases as it does to Signal Sources and invocable Capability Providers — Knowledge Base Providers register at startup, present cost metadata, and serve retrievals under the same lifecycle and trust contract.

3.7.2 Knowledge Base Identity and Manifest

A Knowledge Base MUST have a stable URI of the form:

knowledge-base:<authority>:<domain>:<name>

where <authority> is the issuing organisation (typically a customer Workforce’s authority or a vendor’s authority), <domain> partitions the authority’s namespace, and <name> identifies the Base within the domain. Examples (non-normative):

• knowledge-base:bank-au:policy:credit-risk
• knowledge-base:bank-au:regulatory:asic-bulletins
• knowledge-base:refinitiv:asx-listed:filings
• knowledge-base:bank-au:exemplars:coverage-proposals

Every Knowledge Base MUST publish a manifest declaring at minimum:

• kb_id — the canonical URI.
• owning_workforce — the Workforce that owns and writes the Base (§3.7.4).
• schema — a reference to the schema document describing the content’s structure. For unstructured Bases (document stores), this is a content-type declaration; for structured Bases (vector stores, key-value stores), this is the field schema.
• permitted_capabilities — the set of Knowledge Capability kinds (§3.5.3) the Base accepts retrievals from. A retrieval using a Capability kind not in this set MUST be refused.
• contribution_policy — whether the Base accepts contributions (§3.7.6), and if so, under what gating (auto-accept, curation-required, closed).
• retention — the retention class (§3.7.7).
• export_grants — Workforces (other than the owner) permitted to read this Base under the federation read model (§3.7.5). Default: empty (no external reads).

The manifest is signed by the owning Workforce’s Architect at creation. Manifest changes are themselves audited as KnowledgeBaseRegistered (creation) or as part of KnowledgeBaseVersionCreated events (subsequent manifest revisions are versioned content).

3.7.3 Versioning

A Knowledge Base maintains versions along two tracks:

• Immutable content-hash-addressed versions. Every distinct content snapshot is identified by (kb_id, version, content_hash) where version is monotonic and content_hash is the cryptographic hash of the canonicalised content. Versions MUST NOT be modified or deleted; retirement (§3.7.7) is the only protocol-permitted lifecycle exit for a version.
• Mutable current pointer. A Base has a single current pointer that resolves to a specific version. The pointer is mutable: a KnowledgeBaseCurrentPointerMoved event records each move, signed by the actor who moved it (typically an Architect, possibly a Worker holding write authority in the auto-accept contribution policy case). The pointer is the operator-facing handle (“the live policy”); the resolved (version, content_hash) is the audit-facing record.

A Knowledge Capability invocation MAY target either:

• The current pointer: the Provider resolves to whatever version current points to at retrieval time.
• An explicit (kb_id, version) or (kb_id, content_hash): the Provider returns that exact snapshot.

In both cases the Provider’s response MUST include the resolved (version, content_hash) and the runtime MUST persist all three values on the CapabilityInvoked event per §9.2. Re-fetching at the same (kb_id, version) or (kb_id, content_hash) MUST be guaranteed bit-identical.

3.7.4 Ownership and Scope

A Knowledge Base is owned by exactly one Workforce. Ownership is declared in the manifest, signed at creation, and immutable for the Base’s lifetime. The owning Workforce is the sole writer: only Workers within the owning Workforce, acting under Authority Grants that include the Base, MAY create new versions, move the current pointer, accept contributions, or modify the manifest.

A Knowledge Base’s URI is globally unique by construction (the <authority> segment scopes the namespace), but its governance is owning-Workforce-local. Two Workforces in the same organisation MAY each own Knowledge Bases that share an authority segment (e.g. both under bank-au), but each Base has a single owner.

Multiple-owner Knowledge Bases are not supported by this protocol. Implementations MUST NOT permit ownership transfer of a live Base; the conformant pattern for handing knowledge across Workforces is to retire the original Base, create a new Base under the new owner, and (if continuity is desired) ingest the prior Base’s final version as the new Base’s initial version with a provenance reference.

3.7.5 Federation: Cross-Workforce Read

A Workforce MAY read from a Knowledge Base owned by another Workforce, subject to gates on both sides:

• Reader side. The reading Worker’s Authority Grant (§3.2.4 Knowledge Base authority) MUST include the target Knowledge Base.
• Owner side. The Knowledge Base’s manifest (§3.7.2) MUST list the reading Workforce in its export_grants. The owning Workforce’s Architect grants this explicitly; it is not implied by Base creation.

Where both gates permit, a cross-Workforce read is a Knowledge Capability invocation routed to the owning Workforce’s Knowledge Provider. The retrieval is recorded on the reading Workforce’s Audit Envelope as a CapabilityInvoked event with:

• The standard Knowledge Base reference fields (knowledge_base_id, knowledge_base_version, retrieved_content_hash) per §9.2.
• A provenance reference (§5.1) pointing to the owning Workforce’s envelope and source event that materialised the version (typically a KnowledgeBaseVersionCreated or KnowledgeBaseCurrentPointerMoved event).

The owning Workforce’s envelope is unaffected by the read; reads do not mutate the owning Workforce’s audit chain. The provenance ref enables an auditor on the reading side to walk to the owning side’s evidence chain for the version-creation event, and a regulator on either side to reconstruct the full provenance.

A reading Workforce MAY operate a local replica or cache of an external Knowledge Base. Replication is an implementation strategy: it does not change the federation semantics. When a retrieval is served from a replica, the CapabilityInvoked event MUST record synced_at (the wall-clock time the replica last synced) and kb_version_at_sync (the version the replica held at sync). Staleness is therefore observable from the audit chain.

Cross-Workforce writes are not supported. A Workforce MUST NOT modify (version, current-pointer-move, manifest-change, contribution-accept) a Knowledge Base it does not own. Where two Workforces need to collaborate on knowledge content, the conformant pattern is two Knowledge Bases with a publish/merge workflow: the proposing Workforce owns a draft Base; the canonical Workforce subscribes to a Signal emitted on draft completion (signal:owp:knowledge:contribution-proposed/v1) and merges acceptable proposals into its own Base via the contribution mechanism (§3.7.6).

3.7.6 Contributions (Write Paths)

A Knowledge Base whose contribution_policy is auto-accept or curation-required accepts contributions from Workers in the owning Workforce that hold the relevant Knowledge Base authority (§3.2.4). A contribution is a proposed addition or change to the Base’s content; it is itself an auditable action.

A contribution proceeds as follows:

1. Propose. A Worker emits a KnowledgeContributionProposed event into its current Audit Envelope, carrying the proposed content, the target Knowledge Base, the trigger (e.g. on-decision, on-outcome-feedback, on-anomaly), and a content-hash of the proposal.
2. Gate. Where contribution_policy is auto-accept, the runtime immediately materialises the contribution as a new version (KnowledgeBaseVersionCreated) and, if the current pointer policy is auto-advance, moves current (KnowledgeBaseCurrentPointerMoved). Where contribution_policy is curation-required, the proposal enters a curation queue; an Architect or designated curator (a Human Role with curation authority) reviews and signs an acceptance or rejection.
3. Accept. Acceptance emits KnowledgeContributionAccepted, carrying the resulting version reference and the curator’s signature. The version is materialised; the current pointer is moved per the Base’s policy.
4. Reject. A rejection emits a KnowledgeContributionRejected event (defined as an extension event type for implementations that distinguish; otherwise the proposal simply does not advance). The proposal remains in the Audit Envelope as evidence of the Worker’s attempt.

A contribution_policy of closed MUST cause the runtime to refuse all contributions to the Base, even from Workers in the owning Workforce. Authority on the contribution axis is independent of authority on the read axis: a Worker MAY hold read access without contribution access, or vice versa. A Worker proposing a contribution to a Base it lacks contribution authority on MUST be refused with an authority-violation event.

Contributions cross neither the Provider trust boundary (the Provider for a Knowledge Base is in the owning Workforce) nor the federation boundary (writes are owning-Workforce-local; cross-Workforce proposals follow the publish/merge pattern in §3.7.5).

3.7.7 Retention and Retirement

A Knowledge Base’s manifest declares a retention class that governs how long retired versions are kept:

• permanent — all versions retained indefinitely. Required for Bases whose content informs regulated decisions.
• bounded — versions older than a declared horizon (e.g. seven years) MAY be moved to cold storage but remain content-hash-addressable.
• superseded-only — only the current version and any version referenced by an open (unsealed) Audit Envelope is retained.

The retention class is set at Base creation and SHOULD NOT change over the Base’s lifetime. Changing the retention class MUST be a signed KnowledgeBaseRetentionPolicyChanged event and MUST NOT apply retroactively to versions older than the change.

A Knowledge Base is retired by emitting a KnowledgeBaseRetired event signed by the owning Workforce’s Architect. Retirement is terminal: a retired Base accepts no new retrievals, no contributions, and no version creations. Existing references to retired Base versions (e.g. in sealed Audit Envelopes) remain resolvable in audit-replay mode. A retired Base’s URI MUST NOT be reused for a new Base.

---