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 Instance

3.1.1 Definition

A Worker Instance — informally, a Worker — is an organisational actor with stable identity: the runtime instantiation of a Worker Definition (§3.2). One Worker Definition (the template) is instantiated by many Worker Instances; the relationship is one-to-many. A Worker Instance 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 bound Worker Definition at any moment, as specified in §3.2, which it MAY re-bind per §3.1.7. (Binding to more than one Worker Definition at a single moment does not apply to Workers; concurrent multi-Role holding 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 Worker Definition, 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 Worker Definition.
• 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 Worker Definition at all times. The runtime MUST refuse outbox actions that exceed the Worker Definition’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 Worker Definition (a single Worker Definition; 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 Worker Definition (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 its Episodic Memory (§3.7.2, §3.7.7 — Episodic Memory is a projection over this record). 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.1.7 Re-binding

A Worker Instance is bound to exactly one Worker Definition at any moment, but MAY be re-bound to a different Worker Definition over its lifetime — modelling reassignment or promotion while preserving the Worker’s stable identity and audit history. Re-binding MUST be recorded as a signed, audited WorkerInstanceRebound event; it preserves the Worker ID (§3.1.2) and the Worker’s history (§3.1.6). Re-binding changes which Worker Definition an Instance follows; it does NOT edit a Worker Definition’s charter (that is Recalibration, §12.4). Where identity continuity is not desired, the conformant alternative is decommissioning (§12.5) and instantiating a new Worker.

3.2 Worker Definition

3.2.1 Definition

A Worker Definition is the charter definition for a class of work. A Worker Definition 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 Competency Profile (§3.2.8).
• A Capacity declaration (§3.2.9).
• Output Contracts for the Intent kinds it accepts (§3.2.10).
• Measurement Defaults for the Intent kinds it generates (§3.2.11).
• An Execution Mode — ai or human (§3.2.12).

Every charter component exists to be read by a named runtime consumer (the registry, the Driver, the dispatch gate, Allocation Deliberation, backpressure, output validation, measurement, the Authority Enforcer, the escalation checker, the Signal router). A conformant runtime MUST enforce each component per its section below; a component the runtime does not read is not part of this protocol. This is the no-dead-field principle (ADR-W21): the historical failure mode this draft corrects is charter fields that existed in schemas while enforced nowhere and authored empty, which taught charter authors to relocate load-bearing declarations into the Standing Intent prose where nothing could check them.

All components introduced in Working Draft 0.5 are additive and MUST be omitted from the canonical serialisation when absent, such that Function bundles signed against earlier drafts continue to verify byte-identically (§4.1.5).

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

The single-Worker Definition 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 Worker Definition — composing through Intent dispatch, rather than one Worker with multiple Worker Definitions. 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 Worker Definition binding MAY change over the Worker’s lifetime (e.g. through Recalibration, §12.4), but at any single moment the binding is to one Worker Definition and one Worker Definition only. Charter version changes within the same Worker Definition do not constitute Worker Definition rebinding.

A Worker Definition MUST have a Worker Definition ID of the form:

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

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

3.2.2 Standing Intent

The Standing Intent is a structured statement of the Worker Definition’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 Worker Definition, not to the Worker. A Worker holding the Worker Definition inherits the Standing Intent at the moment of binding and is released from it at the moment of unbinding.

The Standing Intent carries behaviour and tone: who the Worker is, how it reasons, its domain framing. It MUST NOT be the authoritative source for concerns owned by structured charter components: output shapes belong to Output Contracts (§3.2.10), authority bounds to the Authority Grant’s decision-scope clauses (§3.2.4), and work acceptance to the Intent Grammar (§3.2.5). Where the prompt presented to the Worker’s model describes such concerns (a Worker should know its own limits), that prompt text MUST be rendered from the structured component — never authored independently beside it — so the description the model obeys and the rule the runtime enforces cannot diverge. Authoring tools SHOULD warn when a Standing Intent embeds output schemas or authority language.

3.2.3 Signal Subscriptions

A Worker Definition 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 Worker Definition.

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 Worker Definitions to subscribe with finer granularity than kind alone — for example, a “Sector Analyst (Construction)” Worker Definition may subscribe to all market-news Signals filtered to the construction sector.

The subscription declaration is part of the Worker Definition’s charter and is enforced by the runtime. A Worker MUST NOT receive Signals outside its Worker Definition’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 Worker Definition 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”).
• Memory authority. Which Memory items/scopes (§3.7) the Worker may access, and via which operations. Expressed on two independent axes — memory (which items/scopes, an enumeration or pattern over Memory URIs) and memory_capabilities (which operations: read / reinforce / decay / invert / contribute). A Worker MUST hold both a listed Memory item and a listed Memory Capability to operate; either axis MAY be tightened independently (e.g. “may read all of memory:bank-au:semantic:* but reinforce only memory:bank-au:causal:coverage-*, and invert none”). Authority not explicitly granted is implicitly denied on both axes. The autonomy threshold (§3.7.13) is expressed on the operation axis: read, reinforce, and decay are directly grantable for autonomous-but-audited use; invert and Semantic contribute are NOT directly grantable — they route through Recalibration (§12.4, co-signed). The runtime MUST refuse operations where either axis denies, and emit an authority-violation event.
• Dispatch authority. Which Worker Definitions the Worker may dispatch Intents to, and which Intent kinds it may dispatch. A Worker MUST NOT dispatch an Intent kind to a Worker Definition 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, declared as structured clauses — each clause carrying an action category, an optional bound (a typed threshold such as a monetary value, count, or duration), and an on-exceed behaviour (escalate or refuse). Example (non-normative): {category: facility-terms-review, bound: {currency: AUD, max: 1000000}, on_exceed: escalate}. The runtime MUST evaluate the clauses on the relevant action paths: an action within a clause’s bound proceeds; an action exceeding a bound with on_exceed: escalate triggers a REQUIRED escalation per §6.5 (a Resolution attempted in its place MUST be refused); an attempt to bypass either emits an authority-violation event. Free-text decision-scope labels without clauses are permitted only for categories with no evaluable bound. Any prompt text describing the Worker’s decision limits MUST be rendered from these clauses (§3.2.2).
• 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 Worker Definition MUST declare:

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

These two declarations together form the Worker Definition’s Intent Grammar.

The Intent Grammar is enforced bidirectionally:

• The runtime MUST refuse any Dispatch in which the source Worker’s Worker Definition does not generate the Intent kind, or in which the target Worker’s Worker Definition does not accept the Intent kind.
• Where multiple Worker Definitions match an unbound Dispatch (one with no specific target Worker), the runtime MUST select among Worker Definitions 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 Worker Definitions to determine, prior to deployment, which Intents can flow between which Worker Definitions. Reviewers MAY inspect the same to verify regulatory or organisational constraints.

Empty-grammar semantics. An empty accepts declaration means the Worker Definition accepts no dispatched Intent kinds; an empty generates declaration means it generates none. Empty is a statement, not an omission — a runtime MUST NOT treat an empty grammar as permissive. (The permissive reading is how the grammar historically decayed into a decorative field.) Refusals under this section MUST be distinct, citable errors naming the violated clause. Runtimes introducing grammar enforcement over an installed base SHOULD sequence bundle re-authoring ahead of enforcement rather than gate enforcement off indefinitely.

Deliberation interaction. Function Lead Worker Definitions implicitly accept the protocol-defined assessment kind intent:owp:allocation-assess/v1 (§6.12.2); an implementation MAY additionally require its explicit declaration.

3.2.6 Escalation Routes

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

An Escalation Route MUST specify:

• The target Worker Definition (a Worker Definition 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 Worker Definition not declared in the Escalation Routes of its Worker Definition. This prevents accidental authority leakage.

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

Human-seat targets MUST be declared (ADR-W30). An Escalation Route whose target is a human seat — a URI of the form role:<function>/v<n>:human:<name> — MUST be declared in the Function bundle’s human_roles (see below), mapping the seat to its §7 Human Role kind. A runtime MUST refuse, at Function bundle verification, a bundle whose Escalation Routes name a human seat the bundle does not declare: an undeclared human seat is a dangling reference — its §7 kind, and therefore its §4.2.5 binding and its channel, are unknowable. The Function bundle declares its human seats in a human_roles list, each entry {id, kind} where id is the seat URI and kind is one of §7’s four Human Roles (Architect, Reviewer, Resolver, Operator). The channel to reach the human is NOT declared here — it is a per-deployment fact on the §4.2.5 binding (§4.2.5).

3.2.7 Leadership Worker Definition Kinds

In the multi-scale Intent model (§3.4.6), every Workforce MUST contain exactly one Workforce Director Worker Definition, and every Function MUST contain exactly one Function Lead Worker Definition. These are typed kinds of Worker Definition with required Charter fields that the runtime validates at Function bundle load.

The two leadership Worker Definition kinds are:

Worker Definition kind	Charter scope	Decomposes Intents from	Decomposes Intents to	Aggregates Outcomes from
role-kind:leadership/workforce-director	workforce	Authority-level Operator (org-scope Intents)	Function Leads within this Workforce	All Function Leads’ aggregated Outcomes
role-kind:leadership/function-lead	function	The Workforce’s Director (workforce-scope Intents)	IC Workers (per their Worker Definition’s Intent Grammar) within this Function	IC Workers’ operational Outcomes

Org-level direction-setting is performed by an Operator principal (typically a human via the Human Role binding mechanism in §4.2.5), not by a leadership Worker Definition. There is no role-kind:leadership/org-director because at the org level there is no enclosing Workforce or Function to provide leadership within.

A leadership Worker Definition MUST declare execution: ai (§3.2.12); a runtime MUST reject a human leadership Definition. Leadership kinds sit inside synchronous loops — a Director solicits and awards within a bounded assessment window (§6.12), and a Lead’s aggregation readiness is cadence-driven (§6.9) — so a human performing a leadership Worker’s work would make every subtree’s latency human-bounded, not just their own. This is distinct from the §4.2.5 human-or-AI fill of a leadership charter (a leadership role’s authority MAY be exercised by a human via the binding): that concerns authority over the role, not a human executing its synchronous work.

A leadership Worker Definition’s Charter MUST include the following fields in addition to the standard Worker Definition fields (§3.2.1–§3.2.6):

• role_kind — one of role-kind:leadership/workforce-director or role-kind:leadership/function-lead.
• scope — workforce or function; MUST match the structural location of the Worker Definition.
• decomposition_grammar — declares how the leadership Worker decomposes upstream Intents into downstream Intents:
  • prompt_template — the prompt the Worker’s Driver uses when reasoning about decomposition. MAY reference KBs (§3.7) and the upstream Intent’s measurement criteria.
  • target_kinds — the Intent kinds this Worker Definition is permitted to emit downward (a subset of the standard Intent Grammar’s issues clause).
  • target_roles — the Worker Definition IDs in the level below that this leadership Worker Definition MAY dispatch decomposed Intents to.
  • required_decomposition_output_schema — the schema each decomposed Intent MUST satisfy. The runtime MUST refuse decomposed Intents that fail this schema. Every decomposed Intent MUST carry a cascade-originated or strategic-cascade-originated provenance link (§3.4.5) to its upstream Intent.
• aggregation_grammar — declares how the leadership Worker aggregates downstream Outcomes into Outcomes emitted upward:
  • prompt_template — the prompt the Worker’s Driver uses when reasoning about aggregation. MAY reference the upstream Intent’s measurement criteria.
  • source_roles — the Worker Definition IDs whose Outcomes are aggregated.
  • emission_cadence — how often the leadership Worker emits an aggregated Outcome. MUST include on-intent-resolution (emit when the upstream Intent is being marked terminal) AND at least one of daily | weekly | monthly for interim reporting. Continuous narration of in-progress realisation is a hard requirement.
  • output_measurement_schema — the schema the aggregated Outcome’s measurement field satisfies (per §3.4.10).
• requires_tradeoff_narration — set to true. Signals to the runtime that any Outcome emitted by this Worker MUST include structured tradeoff narration (per §3.4.11) when applicable.

Mandatory Presence and Exactly-One Invariant

The runtime MUST enforce the following at all times:

• Every Workforce in the Authority MUST contain exactly one active Worker Definition of kind role-kind:leadership/workforce-director with scope: workforce.
• Every Function within every Workforce MUST contain exactly one active Worker Definition of kind role-kind:leadership/function-lead with scope: function.

“Exactly one” means at least one (silence on cascaded Intents is not acceptable; every scope needs an addressable decomposer) and at most one (multiple decomposers in the same scope would produce divergent decompositions; the protocol forbids this).

These rules MUST be checked at:

• Authoring time — Charter editors (e.g. Apophenic Builder, §7.x ecosystem tooling) MUST refuse to save a Workforce without a Director, or a Function without a Lead. The save action is refused with an actionable error.
• Deployment time — the Function Loader (§4.1.4) MUST refuse Function bundles that fail the presence check at instantiation.
• Recalibration time — Recalibrations (§12.4) that would result in a Workforce or Function losing its sole leadership Worker Definition MUST be refused. The Architect MUST either preserve the leadership Worker Definition or designate a successor in the same Recalibration.

Succession

Replacing the current leadership Worker — swapping an AI Worker for a different AI Worker with an updated Charter, transitioning from human fill to AI fill, or replacing one binding with another — is performed via a single Recalibration that atomically replaces the Worker Definition declaration. The mandatory-presence invariant MUST hold throughout: the Recalibration MUST NOT leave the scope without a leadership Worker Definition, even transiently. The runtime applies the swap as one atomic transaction; if any step fails, the prior leadership Worker Definition remains in place and the Recalibration is recorded with outcome: failed.

Human-or-AI Fill

A leadership Worker Definition MAY be filled by an AI Worker (default) or by a human via the Human Role binding mechanism (§4.2.5). The Charter declaration is the same in both cases; only the fill mode differs.

• An AI Worker filling a leadership Worker Definition has a Driver, an LLM Capability binding, and reasons over decomposition_grammar.prompt_template / aggregation_grammar.prompt_template at runtime.
• A human filling a leadership Worker Definition uses Runner surfaces (§12.2) to perform decomposition + aggregation actions; their decisions are signed by their principal key; reasoning is captured as structured narration via Runner-side forms rather than LLM output.

This enables organisations to begin with human leadership and transition to AI Director / Lead Workers as confidence grows, without re-authoring the Charter.

Worker Definition-Scoping Discipline Corollary

The role-scoping discipline guidance (in docs/human-vs-ai-native.md of the reference implementation) advises authoring fewer, broader AI Worker Definitions than the human-equivalent organisation would have — for IC Worker Definitions. Leadership Worker Definitions follow the OPPOSITE rule: exactly one per scope. Leadership cannot be parallelised; decomposition and aggregation are coordination functions, not execution functions. Workers filling a leadership Worker Definition MAY be replicated for high availability (multiple instances of the same Charter), but only one MUST be active per scope at any given time.

3.2.8 Competency Profile

The Competency Profile is the Worker Definition’s declaration of what it is good at, as distinct from what it may do (the Authority Grant) and what it does (the Standing Intent). It declares, at minimum:

• The domains the Worker Definition claims competence in (an enumeration of domain identifiers or short descriptors).
• The work kinds it claims proficiency at, expressed against Intent kinds where possible.
• Optional qualifying claims (jurisdictions, languages, regulatory regimes, named methodologies).

Competency claims MUST be phrased such that an Evaluation (§12.2) can score them against realised Outcomes — a claim that cannot in principle be confirmed or disconfirmed by measured work is not a competency claim and SHOULD be rejected at authoring time. Competency is declared, then measured: the declaration solves the cold-start problem (a new Worker Definition has no history exactly when allocation needs to route to it), and the Evaluation Service plus Allocation Deliberation’s weighted routes (§6.12.5) correct over-claiming over time — a Lead whose bids systematically overstate its roster’s declared competency produces measurable failures that decay the routes its Function won.

Consumers: Allocation Deliberation bids (§6.12.3, capability match), Evaluation scoring (§12.2).

3.2.9 Capacity

A Worker Definition MUST declare the maximum number of concurrent open Intents a Worker holding it may carry. This gives §6.4.1’s backpressure requirement its concrete charter field: the runtime MUST NOT route Dispatches to Workers at their declared ceiling, MUST queue the Dispatch and emit DispatchQueued when all eligible Workers are at capacity, and MUST supply declared-ceiling and live-load figures as the ground truth for Allocation Deliberation bids (§6.12.3) — Leads narrate over runtime-supplied capacity, they do not invent it.

Capacity is a Definition-level declaration; per-Instance runtime variation (current load, health) is runtime state, not charter content.

Consumers: backpressure (§6.4.1), deliberation bids (§6.12.3), routing selection (§6.3).

3.2.10 Output Contracts

A Worker Definition MAY declare, per Intent kind it accepts, an Output Contract: a schema the Outcome’s structure must satisfy at resolution. The runtime MUST validate the Outcome against the declared contract and MUST refuse structurally non-conformant Resolutions with a distinct, citable error, returning the failure to the Worker’s Driver (which MAY retry).

Output Contracts validate structure, never content. A field typed as free text is never constrained beyond its type: an email body, a rationale paragraph, a talking point remains entirely the Worker’s generative output. The contract exists to catch the failure mode machines should catch — the Outcome has the wrong shape entirely, leaving downstream consumers and measurement nothing to evaluate — while leaving the judgement of quality to measurement criteria (§3.4.10), which MAY themselves be judgement-based. A conformance test for this section MUST include a case where an unusual but structurally valid free-text payload passes.

An accepted Intent kind without a declared contract is unconstrained (the pre-0.5 behaviour). Leadership Worker Definitions already carry the analogous machinery for decomposition and aggregation output (§3.2.7); this section extends the pattern to individual-contributor output.

Consumers: Resolution validation (§6.6), measurement (§3.4.10).

3.2.11 Measurement Defaults

A Worker Definition MAY declare, per Intent kind it generates, default measurement criteria (per the §3.4.10 schema). An Intent declared without explicit measurement_criteria inherits the default declared for its kind by the generating Worker Definition; explicitly declared criteria always take precedence. Where neither exists, §3.4.10’s existing requirement applies unchanged (the Intent is refused for absent criteria).

This closes the gap between §3.4.10’s per-Intent requirement and authoring reality: routine Intent kinds measured the same way every time declare that fact once, on the Definition, rather than on every declaration.

Consumers: Intent declaration validation (§3.4.10), Outcome measurement (§6.6).

3.2.12 Execution Mode (Human Workers)

A Worker Definition MUST declare an execution mode, one of ai (the default, for back-compatibility with Definitions authored before this section) or human. The mode declares how the work is performed, not what work it is: a human Definition carries the same charter — Standing Intent (§3.2.2), Intent Grammar (§3.2.5), Authority Grant (§3.2.4), Competency Profile (§3.2.8), Capacity (§3.2.9), Measurement Defaults (§3.2.11) — as an ai Definition, and is allocated work by the same machinery (Allocation Deliberation, §6.12). The distinction is that a Human Worker performs the work asynchronously, over a channel, and signs its Outcome with a human principal key.

A human Definition:

• MUST NOT carry LLM-runtime configuration (driver, model, tool-loop, or prompt fields). A runtime MUST reject a human Definition that declares them: such fields can have no effect on a human, and their presence misrepresents how the work is performed.
• MUST declare channels — one or more {kind, address} entries, where kind names an integration adapter (§8) over which the runtime reaches the human, and address is the destination. A human Definition with no channel cannot receive dispatched work and MUST be rejected at authoring.
• MUST declare response_ttl — the bound within which the human must accept a dispatched Intent before it is swept missed (§3.4.2). It is the human’s own declaration of their responsiveness, and it is what keeps a Human Worker in the allocation pool from ever stalling the organisation (§3.4.2).

A Worker Instance of a human Definition binds to a principal (the human’s key), not to a worker-host. The instance’s actions are signed by that principal (§9.2). One principal MAY hold both human Worker Instances and §4.2.5 Human Role bindings concurrently; these are distinct roles of one identity (§4.2.5, §7).

The channels on a human Definition and the channel on a §4.2.5 Human Role binding share the same shape and the same §8 adapter boundary. A Worker carries its own because a Worker’s reachability is part of its standing declaration; a bound seat’s channel is a per-deployment fact on the binding. Both resolve to “reach this principal here.”

Consumers: Worker Definition validation (authoring + deploy), Allocation Deliberation (§6.12.3 — a Human Worker is roster ground truth), dispatch (§6.3 / §6.8 — delivery over the channel), the missed sweep (§3.4.2 / §6.6).

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, a Reviewer-refused Outcome.
• 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 Worker Definition 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 Worker Definition 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, Human, or Memory 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 Worker Definition 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 Worker Definition 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 declaration of will at a defined scope. It is the unit by which an organisation directs itself: a CEO declares strategic Intent (“position apples as a superfood”); a Workforce Director decomposes that into tactical Intents for the Functions below; Function Leads decompose those into operational Intents for individual Workers; Workers pursue operational Intents and dispatch sub-Intents among themselves.

Intent is the verb of the protocol at every scale. A Function specifies what kinds of Intent its Worker Definitions can generate and accept. A Workforce, at any moment, is a set of declared Intents being pursued. The history of an Authority is the closed set of resolved Intents at every scope.

An Intent’s scope (§3.4.6) determines who can declare it, who decomposes it, and how its realisation is measured. An Intent’s resolution (§6.6) is the measured realisation of the Intent, scored against the success criteria the Intent declared at declaration time.

The Intent’s declared description/payload is the statement of desired outcome — the goal in spirit. The protocol does not define a separate desired_outcome field; the will is intrinsic to the Intent. §6.6 relates three distinct things that MUST NOT be conflated: the desired outcome (this Intent), the measurement(s) (the machine-evaluable proxies that score realisation, §3.4.10), and the Outcome (the realised result of execution). Authoring guidance: an Intent description SHOULD be expressive enough to capture the goal in spirit, because Outcome-gap detection (§3.4.12) compares the delivered Outcome against it.

3.4.2 Intent Lifecycle

An Intent has exactly one non-terminal state and exactly four terminal resolution kinds:

• declared. The Intent has been signed by the originator and accepted into the runtime. Between declared and a terminal state, the Intent is implicitly being realised. There is no separate in-realisation state.

The terminal resolution kinds are:

• achieved — measurement criteria met at evaluation time. The Outcome record (§6.6) carries the measurement score, which MUST satisfy the declared target.
• not-applicable — the receiver deliberately chose to take no action. An affirmative non-action, signed by the responding party. This subsumes all “I won’t take this on” cases: a Workforce Director resolving a cascaded Strategic Intent that doesn’t apply to its Workforce; a Worker declining a dispatched sub-Intent as duplicate, out-of-scope, infeasible, or policy-violating; any active decision not to advance the work. The receiver’s reason is carried as a structured reason field on the Outcome record.
• withdrawn — the originator (or the org acting on its behalf) explicitly cancelled. Used in amendment-by-supersession (§3.4.7), in operational cancellation, and in Worker decommissioning where the runtime terminates an in-flight Intent.
• missed — TTL reached without achieved resolution, and without active termination. A passive failure — timeout, deadline elapsed, no Worker available to advance the Intent. The Outcome record’s measurement score MUST be present (if criteria were declared) and MUST NOT satisfy the target.

Escalation is not a terminal kind. An escalated Intent is in the declared state with an additional escalated marker; resolution flows back to the original Intent per §6.5 once the escalation recipient terminally resolves the escalated form.

Human Worker accept-TTL. When an Intent is dispatched (§6.3 / §6.8) to a Worker Instance of a human Definition (§3.2.12), the runtime MUST deliver it over the Definition’s declared channel (§8) and MUST stamp an accept-deadline of the Definition’s response_ttl. If the human accepts within the deadline, pursuit proceeds and the human’s terminal IntentResolved is signed by their principal (§9.2). If the deadline elapses without acceptance, the Intent is swept missed (per §6.6), and the dispatching authority MUST re-dispatch to a capable AI peer or escalate per §6.5 — the runtime MUST NOT leave the Intent stalled on a non-responding human. This is the property that lets a Human Worker be an allocation candidate (§6.12.3) without ever stalling the organisation: it never waits on a human beyond a bound the human themselves declared, and it reuses the same missed sweep that already bounds assessment-Intent non-response (§6.12.2).

OWP-2 Working Draft 0.3 supersedes the prior Working Draft 0.2 verdict set (achieved | refused | abandoned). The pre-0.3 refused verdict is folded into not-applicable (with the refusal reason carried in reason); the pre-0.3 abandoned verdict is folded into missed (for passive timeout) or withdrawn (for active org decommissioning). Implementations of Working Draft 0.3 emit only the four-kind set. Because OWP-2 is pre-release, no backwards-compatibility shim is required; downstream implementation work migrates to the four-kind set directly.

State transitions MUST be recorded in the Audit Envelope (§9). The runtime MUST refuse transitions not permitted by this lifecycle, and MUST refuse any transition to a terminal state that is not signed by an authorised party per §6.6.

For Strategic Intents (and other higher-scope Intents with declared TTL or measurement criteria), the runtime MUST NOT auto-apply terminal transitions. It MUST emit a StrategicIntentTransitionSuggested (or scope-appropriate equivalent) event when the conditions for achieved or missed are observed; the originator (or their delegate) MUST sign the actual transition. Human-authorised state change at the strategic level is a load-bearing property — runtime observations are advisory.

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 Worker Definitions in their Intent Grammar (§3.2.5). Leadership Worker Definitions (§3.2.7) declare additional Intent-kind constraints via their decomposition_grammar.target_kinds — the Intent kinds they are permitted to emit downward.

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 scope — one of org | workforce | function | worker (§3.4.6). The scope determines the originator type, the decomposition path, and the measurement evaluation semantics.
• A creation timestamp.
• A creating party — the principal (human Operator at org scope; Workforce Director Worker at workforce scope; Function Lead Worker at function scope; any Worker / Human Role / Capability Provider at worker scope) that signed the Intent declaration.
• A target — the Worker ID, Worker Definition, or Workforce / Function / Authority to which the Intent is addressed. The target depends on scope: org Intents target one or more Workforces (or all Workforces in the Authority); workforce Intents target one or more Function Leads; function Intents target one or more IC Worker Definitions or Workers; worker Intents target a specific Worker or unbind to a Worker Definition pool per §6.4.
• A payload, conformant with the schema referenced by the kind URI.
• Measurement criteria — the declared success criteria for this Intent, per the MeasurementCriterion schema (§3.4.10). Measurement criteria are MANDATORY at declaration time. An Intent without declared criteria MUST be refused by the runtime.
• A supersession link (§3.4.7) — if this Intent supersedes a prior Intent, a supersedes: <intent-id> reference. Mirrored on the prior Intent’s superseded_by field at supersession time.
• A provenance chain — the prior Intents (if any), Signals (if any), and Strategic Intent registry references (if any) that gave rise to this Intent (§3.4.5).
• An authority binding — the Authority Grant under which the Intent was generated (the Worker Definition and clause that authorise its creation).
• Bounds — cost ceiling, deadline (TTL), decision scope. Bounds inherit from the generating party’s Authority Grant unless the generator explicitly tightens them.
• A current state (declared or a terminal resolution kind per §3.4.2).
• 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",
  "scope": "worker",
  "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..."
    ]
  },
  "measurement_criteria": {
    "kind": "outcome-aggregation",
    "outcome_aggregation": {
      "scope": "worker",
      "aggregator": "all-achieved"
    },
    "target": { "op": "=", "value": true }
  },
  "supersedes": null,
  "provenance": {
    "originating_signal": "sig:01HXXJ3F2K8N0QRSTUV001",
    "parent_intent": null,
    "strategic_intent_ref": 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": "declared",
  "resolution": null
}

3.4.5 Intent Provenance

Every Intent MUST record its provenance: the originating Signal (if any), the parent Intent (if any), and the upstream Intent in the cascade chain (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 (sub-Intent dispatch): generated by a Worker as a sub-Intent of an Intent it is pursuing. The parent Intent ID MUST be recorded.
• Cascade-originated: generated by a leadership Worker as the decomposition of an upstream Intent at a higher scope (e.g. a Function Lead emits operational Intents in response to a Workforce-scope Intent it received). The upstream Intent ID MUST be recorded.
• Strategic-cascade-originated: a Workforce Director’s decomposition of a Strategic Intent. The Strategic Intent’s registry reference (per §9.x) 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 (§3.2.2) 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.
• Supersession-originated: declared as a replacement for a withdrawn prior Intent. The superseded Intent ID MUST be recorded (§3.4.7).

Provenance enables post-hoc reconstruction of any chain of work at any scope. The Audit Envelope (§9) at the Worker, Function, and Workforce scopes is rooted at the originating Intent at that scope. Strategic Intents do not use envelopes; they live in the per-Authority Strategic Intent Registry (§9.x) and are linked from operational envelopes via provenance references.

3.4.6 Intent Scope

Intent scope is the axis along which an organisation directs itself. Every Intent declares exactly one scope from the following set:

Scope	Declared by	Decomposed by	Typical example
org	Operator principal with org-level Authority	Workforce Director Worker (in each Workforce)	“Position apples as superfood by end of FY26”
workforce	Workforce Director Worker	Function Lead Worker (in each Function)	“Marketing Workforce: re-message the apple line as superfood this quarter”
function	Function Lead Worker	IC Workers within the Function	”Campaign Function: produce 3 superfood-positioning creative concepts”
worker	Any Worker (sub-Intent dispatch); also Signal-triggered Standing Intent firings	The receiving Worker	”Designer Worker: produce visual mockup for concept 2”

Scope is structural: the same Intent kind URI MAY appear at multiple scopes if the URI’s schema permits, but the meaning of an Intent depends on its scope. worker-scope Intents are the existing OWP-2 Intent semantics from earlier drafts (request/task between Workers, including sub-Intent dispatches per §3.4.5 and Standing-originated emissions per §3.2.2). Standing Intent remains a worker-scope variant; it is not a separate scope.

The runtime MUST enforce per-scope authorisation:

• org-scope Intents MUST be signed by a principal with org-level Authority (per §6.7).
• workforce-scope Intents MUST be signed by the active Workforce Director Worker for the target Workforce (per §3.2.7).
• function-scope Intents MUST be signed by the active Function Lead Worker for the target Function.
• worker-scope Intents follow the existing Authority Grant evaluation path.

A leadership Worker emitting a decomposed Intent at the next scope down MUST record the upstream Intent ID in its cascade-originated provenance (§3.4.5).

3.4.7 Supersession

Intent content (scope, kind, measurement criteria, target, payload, declared text) is immutable once signed. To amend an Intent’s content, the originator:

1. Declares a new Intent with the amended content and a supersedes: <old-intent-id> provenance link.
2. Withdraws the old Intent with a resolution of withdrawn and a superseded_by: <new-intent-id> link in the Outcome record.

Both events MUST be signed by the originator (or a principal with explicit succession authority for that originator). Auditors reconstruct the amendment history by walking the supersedes / superseded_by chain. There is no amended lifecycle state; amendment is two coordinated declarations.

In-flight downstream work — operational Intents already accepted and being pursued under the old Intent’s decomposition — continues to resolve under the old Intent’s framing. New decompositions from leadership Workers reflect the superseding Intent’s framing. The runtime MAY surface in-flight downstream work to the originator at supersession time as an attention item; whether to also withdraw downstream Intents is the originator’s choice, signed as additional withdrawals.

3.4.8 Concurrent Streams and Competing Intents

The Strategic cascade is additive, not exclusive. A Worker receiving operational Intents derived from a higher-scope cascade continues to:

• Subscribe to Signals (which MAY trigger Standing Intent firings per §3.2.2)
• Accept sub-Intent dispatches from peer Workers (per §3.4.5 Intent-originated)
• Generate Intents per its Intent Grammar (§3.2.5)

The Worker’s Intent queue is just a queue; cascade-originated Intents join the queue alongside Signal-originated and Intent-originated ones. Authority Enforcement (§6.7) gates each Intent regardless of origin. There is no priority primitive at the protocol level; prioritisation is the receiving Worker’s reasoning concern.

Two Intents at the same scope MAY pull in opposite directions (“cut OPEX 10%” and “expand into 3 new markets”). The protocol does NOT attempt to resolve such conflicts at declaration time. Instead:

• Each leadership Worker makes local tradeoff choices when reconciling competing Intents.
• Those choices are captured as tradeoff narration on the Outcome the leadership Worker emits (see §3.4.11 and §6.6).
• Operators observe the cumulative tradeoff narration via Runner surfaces and Recalibrate (§12.4) when the org’s stated direction needs adjusting.

Conflict between Intents is a normal organisational reality. The protocol’s role is to make conflict observable and adjustable, not to prevent it.

3.4.9 Standing Intent

Standing Intent is defined in §3.2.2 as a Worker Definition’s persistent mandate. In the multi-scale model, Standing Intent is a worker-scope variant: it emits one-shot worker-scope child Intents over time in response to Signals or temporal triggers. Standing Intent is not a separate scope and not a higher-scope cascade.

A Standing Intent firing in response to a Signal MUST record the originating Signal in the child Intent’s provenance (§3.4.5 Signal-originated). A Standing Intent firing on its own temporal cadence (no Signal trigger) MUST record the Standing Intent’s clause ID in the child Intent’s provenance (§3.4.5 Standing-originated).

3.4.10 Measurement Criteria

Every Intent at every scope declares its measurement_criteria at declaration time. The criteria specify how the realisation of the Intent will be scored. The schema is:

MeasurementCriterion = oneOf:
  - { kind: "memory-query", memory_query: { memory_id, query, expected_shape? }, target: <Target> }
  - { kind: "signal-stream", signal_stream: { stream_uri, field_path }, target: <Target> }
  - { kind: "outcome-aggregation", outcome_aggregation: { scope, aggregator, filter? }, target: <Target> }
  - { kind: "combinator", combinator: "and" | "or" | "weighted-sum-threshold",
      operands: [MeasurementCriterion, ...],
      weights?: [number, ...],     # required when combinator = weighted-sum-threshold
      threshold?: number }          # required when combinator = weighted-sum-threshold

Target = { op: ">" | ">=" | "<" | "<=" | "=" | "!=" | "in" | "not-in", value: <scalar | array | object> }

Where:
  memory_query.memory_id      — a registered Memory item URI (§3.7)
  memory_query.query          — a query string in the Memory item's query dialect
  signal_stream.stream_uri    — a registered Signal kind URI (§3.3.3)
  signal_stream.field_path    — JSONPath into the Signal payload
  outcome_aggregation.scope   — "workforce" | "function" | "worker" (the scope of Outcomes being aggregated)
  outcome_aggregation.aggregator — "count" | "sum" | "avg" | "min" | "max" | "any-achieved" | "all-achieved"
  outcome_aggregation.filter  — optional JSON predicate over Outcomes
  combinator.weights          — must have same length as operands
  combinator.threshold        — for weighted-sum-threshold: pass if weighted sum >= threshold

The criterion is recursive: combinator.operands are themselves MeasurementCriterion objects. This enables expressions like “revenue +12% YTD AND brand-survey lift ≥ 8pp” with leaf criteria nested under a top-level combinator.

The runtime MUST validate measurement_criteria against this schema at declaration time. An Intent with invalid criteria MUST be refused with an actionable error.

The runtime MUST evaluate criteria at well-defined moments: (a) on demand when computing an Outcome score; (b) at the leadership Worker Definition’s declared emission_cadence for higher-scope Intents; (c) at TTL. A criterion that cannot be resolved (e.g. memory_query.memory_id references a non-existent Memory item, or signal_stream.stream_uri is unregistered) MUST emit a MeasurementEvaluationFailed audit event rather than silently passing.

measurement_criteria is part of the signed Intent payload. Auditors verifying the signature reconstruct the criteria via RFC 8785 JCS canonical-JSON (per ADR-W04).

Example (non-normative) — a simple Strategic Intent measurement criterion:

{
  "kind": "signal-stream",
  "signal_stream": {
    "stream_uri": "signal:bank-au:erp:revenue.monthly",
    "field_path": "$.apple_line.ytd_pct_change"
  },
  "target": { "op": ">=", "value": 12.0 }
}

Example (non-normative) — a composite criterion combining three signals with weights:

{
  "kind": "combinator",
  "combinator": "weighted-sum-threshold",
  "weights":   [0.5, 0.3, 0.2],
  "threshold": 0.7,
  "operands": [
    {
      "kind": "signal-stream",
      "signal_stream": {
        "stream_uri": "signal:bank-au:erp:revenue.monthly",
        "field_path": "$.apple_line.ytd_pct_change"
      },
      "target": { "op": ">=", "value": 12.0 }
    },
    {
      "kind": "signal-stream",
      "signal_stream": {
        "stream_uri": "signal:bank-au:brand-survey.quarterly",
        "field_path": "$.apple.awareness_pct"
      },
      "target": { "op": ">=", "value": 25.0 }
    },
    {
      "kind": "outcome-aggregation",
      "outcome_aggregation": {
        "scope": "workforce",
        "aggregator": "count",
        "filter": { "outcome_kind": "outcome:retailer-adoption" }
      },
      "target": { "op": ">=", "value": 40 }
    }
  ]
}

3.4.11 Tradeoff Narration

When a leadership Worker (§3.2.7) emits an Outcome and two or more Intents at the same scope are active (in declared state), the Outcome MUST include a tradeoff_narration object. The schema is:

TradeoffNarration = {
  competing_intents: [ { intent_id, scope }, ... ]      # MUST have ≥ 2 entries
  choice_made:      { prioritised_intent_id, summary }  # summary ≤ 500 chars
  costs:            [ { deprioritised_intent_id, consequence }, ... ]  # consequence ≤ 500 chars
  reasoning:        string                              # 50–2000 chars, LLM or human-authored, signed
}

tradeoff_narration is REQUIRED when the conditions above hold. When fewer than two Intents are active in the scope, or when the leadership Worker’s reasoning was uninfluenced by other active Intents, tradeoff_narration MAY be omitted. The runtime MUST track active Intent counts per scope; if the count is ≥ 2 and a leadership Worker emits an Outcome without narration, the runtime MUST emit a TradeoffNarrationOmissionDetected audit event for human review. Omission is not refused (operationally it would be too noisy) but is audited.

tradeoff_narration is part of the signed Outcome payload. The narration’s reasoning field MAY be authored by an LLM (in the AI-filled leadership Worker Definition case) or by a human (in the human-filled leadership Worker Definition case via Human Role binding).

3.4.12 Outcome Gap

Because measurement criteria (§3.4.10) are proxies for the desired outcome (the Intent, §3.4.1), the delivered Outcome (§6.6) may diverge from what the Intent actually sought even when the measures pass — and may satisfy the Intent even when the measures fail. The runtime surfaces this divergence as a first-class, advisory signal.

An OutcomeGapObserved audit event (§9.1) MUST be emitted, conservatively, when there is a divergence among (a) the desired outcome (the Intent), (b) the measurement score, and (c) the delivered Outcome or Reviewer disposition, in one of two canonical forms:

• proxy-gaming — measurement criteria satisfied, but the delivered Outcome does not satisfy the Intent’s stated will (or is Reviewer-refused).
• bad-measure — the delivered Outcome satisfies the Intent’s will, but the measurement criteria were not satisfied.

OutcomeGapObserved is advisory (like the transition suggestions of §3.4.2): it auto-resolves nothing; it is recorded, surfaced to Reviewers and Operators, and fed to Causal Memory. Determining whether a delivered Outcome “satisfies the Intent’s will” MAY require a Reviewer disposition or an LLM-assisted alignment check; implementations SHOULD reserve the check for Intents that request it or for Reviewer-flagged cases, to bound noise.

The three-way gap — not the raw measurement score — is the causal-attribution input to the Causal Memory reinforce/decay/invert engine (§3.7.5). A Causal Memory item linked (via Intent provenance, §3.4.5) to Intents whose delivered Outcomes satisfy their will is reinforced; one linked to repeated OutcomeGapObserved of the proxy-gaming form decays and ultimately inverts. This is the safeguard against Causal Memory learning to game measures.

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:memory: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.
• Memory Capabilities. Invocations through which a Worker reads and writes the Memory primitive (§3.7). Operations are explicit kinds so authority may be granted asymmetrically: read, reinforce, decay, invert, contribute. Examples: semantic query, causal-belief read, reinforce-on-outcome, counterparty update. The Capability defines the operation (the shape of the operation and its response); the Memory item it resolves against defines the asset (the governed content or belief). Both axes are required: a Worker MUST hold both Memory Capability authority and Memory authority under its Authority Grant (§3.2.4). Reads emit MemoryRead; writes emit the corresponding Memory* update event (§3.7.6). All Memory Capability invocations are authority-gated (§6.7), audited (§3.6), and cost-metered (§10) — Memory access carries no exemption from the single-observation-point property (§3.5.1). The Provider MUST return the resolved Memory version, content hash, and confidence-at-read 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 Worker Definition 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 Worker Definition 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 Memory

3.7.1 Definition

Memory is a governed organisational substrate that a Worker reads from and writes to. Memory is a first-class OWP-2 primitive. It subsumes and replaces the Knowledge Base primitive of Working Draft 0.2: organisational knowledge is one kind of Memory (Semantic, §3.7.2), sitting alongside learned causal belief, the episodic record, working context, the Worker Definition’s constitution, and counterparty knowledge.

Memory is a primitive, not a parameter on a Capability invocation. A Memory item is identifiable by URI, typed by kind (§3.7.2), scoped (§3.7.3), and — for the dynamic kinds — carries a confidence that evolves as a function of the Outcomes it causally contributed to (§3.7.5). The Audit Envelope MUST reference Memory by (memory_id, memory_version, content_hash, confidence_at_read) on every read (§9.2); a regulator or Reviewer asking “what did this Worker know or believe when it decided, and why?” MUST receive a deterministic, content-addressed, provenance-linked answer.

Memory is distinguished from a Capability by its statefulness and from a Worker by its passivity. A Capability invocation is stateless; Memory is state a Worker reads and writes. The read/write transport is the Memory Capability (§3.5.3), gated by Authority Grant (§3.2.4) and routed through the Provider trust boundary (§8) — Memory Providers register at startup, present cost metadata, and serve reads and writes under the same lifecycle and trust contract as Signal Sources and other Capability Providers.

3.7.2 Memory Kinds

The protocol distinguishes six kinds of Memory:

Kind	What it remembers	Volatility	Default scope	Truth dynamics
Causal	”In context C, approach A tends to produce Outcome O”	updates per Outcome	Worker Definition	reinforce / decay / invert
Episodic	a specific event that occurred	append-only	Worker Instance	none — it is the record (§3.7.7)
Semantic	durable domain fact, policy, reference content	curated, slow	Function / Workforce	curated revision
Working	in-flight context for the current Intent	ephemeral	Worker Instance, Intent-scoped	discarded at resolution
Constitutional	the Worker Definition’s charter / mandate	amendment-only	Worker Definition	Recalibration (§12.4)
Relational	what is known about a counterparty	per-interaction	Worker Definition / Workforce	reinforce / decay

The kinds differ in volatility and truth dynamics, not in nature; they are one substrate. Semantic Memory is the direct successor of the Working-Draft-0.2 Knowledge Base and inherits its versioning, ownership, federation, contribution, and retention machinery (§3.7.8–§3.7.12).

3.7.3 Memory Scope

Every Memory item declares a scope on the axis instance | definition | function | workforce (mirroring Intent scope, §3.4.6). Sharing is a scope decision, not an accident: instance-scope Memory is private to one Worker Instance; definition-scope Memory is shared by all Instances of a Worker Definition; function/workforce-scope Memory is shared more broadly. Promotion of a Memory item to a wider scope MUST be a signed, audited act.

3.7.4 Memory Identity and Manifest

A Memory item MUST have a stable URI of the form:

memory:<authority>:<kind>:<name>

where <kind> is one of the six kinds (§3.7.2). Examples (non-normative):

• memory:bank-au:semantic:credit-risk-policy
• memory:bank-au:causal:coverage-retention
• memory:bank-au:relational:customer-c1029384
• memory:refinitiv:semantic:asx-listed-filings

Every Memory item MUST publish a manifest declaring at minimum: memory_id (canonical URI), kind, scope, owning_workforce (§3.7.9, for Semantic/Relational), schema (content structure), permitted_capabilities (the Memory Capability kinds it accepts operations from), contribution_policy (§3.7.11, Semantic), retention (§3.7.12), and export_grants (§3.7.10, default empty). The manifest is signed by the owning Workforce’s Architect at creation and audited as MemoryRegistered.

3.7.5 Confidence and Truth Dynamics

For Causal and Relational Memory, confidence is never mutated in place. Each change is an append-only signed update event (§3.7.6) recorded in the relevant Audit Envelope, carrying provenance to the Outcome(s) that justified it. The current confidence of a Memory item is a deterministic fold over its update-event sequence; the runtime MUST be able to reconstruct an item’s confidence at any past point by folding its events up to that point.

• Reinforce. An Outcome causally attributed to the item satisfied its Intent (per the three-way gap, §3.4.12 / §6.6); confidence increases.
• Decay. Confidence erodes with time or disuse absent reinforcing evidence, so stale beliefs fade rather than persist forever.
• Invert. When accumulated counter-evidence crosses a declared threshold, the assertion flips sign. Inversion is a distinct first-class transition — the difference between “I no longer know” and “I now believe the opposite.”

The confidence-update function MUST be deterministic and bounded (no single update or run of updates may move confidence without bound). The causal-attribution input — which Outcome justifies which confidence change — is the Intent↔Outcome↔Measurement gap defined in §6.6, not the raw measurement score; this is the safeguard against Memory learning to game measures.

3.7.6 Memory Update and Read Events

The following audit event kinds (§9.1) record Memory operations: MemoryReinforced, MemoryDecayed, MemoryInverted, MemoryContributed, MemoryRead. Every event MUST be signed by the actor and verified at append time (§3.6, §9.3). Reinforce/decay/invert events MUST carry Outcome provenance (§5.1). A MemoryRead records (memory_id, resolved_version, content_hash, confidence_at_read).

3.7.7 Episodic Memory as Envelope Projection

Episodic Memory is not a separately persisted store. It is a read projection over the immutable Audit Envelope (§3.6, §9): “what this Worker did and saw” is a query over envelope events, not a duplicate of them. Episodic Memory therefore does not evolve — the record does not evolve. This is the reconciliation of “Memory evolves” with envelope immutability: only the interpretation of the record (Causal belief) evolves, and it does so through separate, signed update events (§3.7.6). Implementations MUST NOT maintain a second source of truth for episodic content.

3.7.8 Semantic Memory: Versioning

Semantic Memory maintains versions along two tracks, inherited from the Working-Draft-0.2 Knowledge Base:

• Immutable content-hash-addressed versions. Every distinct content snapshot is identified by (memory_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.12) is the only lifecycle exit.
• Mutable current pointer. A single current pointer resolves to a specific version; each move is a signed MemoryCurrentPointerMoved event. The pointer is the operator-facing handle; the resolved (version, content_hash) is the audit-facing record.

A Memory read MAY target the current pointer or an explicit (memory_id, version) / (memory_id, content_hash). In all cases the Provider’s response MUST include the resolved (version, content_hash), persisted on the MemoryRead event per §9.2. Re-reading at the same (memory_id, version) MUST be guaranteed bit-identical.

3.7.9 Ownership

A Semantic or Relational Memory item is owned by exactly one Workforce, declared in the manifest, signed at creation, and immutable for the item’s lifetime. The owning Workforce is the sole writer of durable content. URIs are globally unique by construction; governance is owning-Workforce-local. Multiple-owner Memory is not supported; the conformant pattern for handing memory across Workforces is retire-and-recreate with a provenance reference.

3.7.10 Federation: Cross-Workforce Read

A Workforce MAY read a Semantic/Relational Memory item owned by another Workforce, subject to gates on both sides: the reading Worker’s Authority Grant (§3.2.4 Memory authority) MUST include the target item, and the item’s manifest MUST list the reading Workforce in its export_grants. Where both gates permit, the cross-Workforce read is a Memory Capability invocation recorded on the reading Workforce’s Audit Envelope with the standard Memory reference fields (§9.2) and a provenance reference (§5.1) to the owning Workforce’s version-creation event. Reads do not mutate the owning Workforce’s chain. Replicas MUST record synced_at and memory_version_at_sync so staleness is observable. Cross-Workforce writes are not supported; collaboration follows the publish/merge pattern (a proposing Workforce owns a draft item; the canonical Workforce merges via §3.7.11).

3.7.11 Contributions (Semantic Write Paths)

A Semantic Memory item whose contribution_policy is auto-accept or curation-required accepts contributions from Workers in the owning Workforce holding the relevant Memory authority (§3.2.4). A contribution proceeds: Propose (MemoryContributed, carrying proposed content, target item, trigger, content-hash) → Gate (auto-accept materialises a new version immediately; curation-required enters a curation queue for a Human Role with curation authority) → Accept (MemoryContributionAccepted, version reference + curator signature) → Reject (proposal does not advance; the MemoryContributed event remains as evidence). A closed policy refuses all contributions. Contribution authority is independent of read authority. Semantic contribution — unlike autonomous Causal reinforce/decay — routes through the co-signed path (§3.7.13).

3.7.12 Forgetting, Retention and Retirement

Operational forgetting (a Memory item ceases to influence behaviour) is a tombstone update event that drops confidence to null; it does not delete history. Evidentiary retention: the envelope still records that the item existed and why it was dropped. Right-to-be-forgotten obligations are therefore satisfiable at the operational layer without violating envelope immutability (§3.6, and the operating rule that sealed envelopes are immutable).

A Semantic Memory item’s manifest declares a retention class governing retired versions: permanent (all versions retained indefinitely; required where content informs regulated decisions), bounded (versions older than a declared horizon MAY move to cold storage but remain content-hash-addressable), or superseded-only (only current and versions referenced by open envelopes retained). Retirement emits a signed MemoryRetired event; a retired item accepts no new reads, contributions, or versions, but existing references remain resolvable in audit-replay mode. A retired URI MUST NOT be reused.

3.7.13 Governance (Autonomy Threshold)

Reinforce and decay of Causal and Relational Memory MAY be performed autonomously by a Worker, but MUST be audited (§3.7.6). Invert of a Causal Memory item, and any revision or contribution to Semantic Memory, materially change behaviour and MUST route through Recalibration (§12.4, co-signed). Constitutional Memory (the Worker Definition’s Charter) is amendment-only via Recalibration. This keeps Memory and the Continuous-Evolution loop a single governed system rather than two.