6. Runtime Behaviour

This section specifies the behavioural semantics of the protocol — the runtime guarantees that any conforming implementation MUST provide. The section is structured by operation: signal delivery, intent generation, intent acceptance and pursuit, dispatch, escalation, resolution, and authority enforcement.

6.1 Signal Delivery

The runtime MUST deliver Signals to Workers whose Worker Definitions subscribe to the Signal’s kind, subject to any subscription filters declared in the Worker Definition.

Delivery is governed by the following guarantees:

At-least-once delivery. A subscribed Worker MUST receive the Signal at least once. Exactly-once delivery is NOT REQUIRED; Workers MUST be tolerant of duplicate Signals (idempotency).
Per-source ordering. Signals from a single source MUST be delivered to a given Worker in the order they were emitted by that source. Cross-source ordering is NOT REQUIRED.
Bounded latency. Implementations MUST publish a maximum delivery latency for their deployment. Compliance Profiles MAY tighten this bound.

The protocol does not prescribe a delivery mechanism (push, pull, queue, stream). Any mechanism that provides the above guarantees is conforming.

6.2 Intent Generation

A Worker MAY generate an Intent in response to:

A delivered Signal.
A Standing Intent expression that calls for periodic or condition-driven action.
An action it is taking in pursuit of an open Intent (i.e. generating a sub-Intent).

Intent generation produces an Intent structure as specified in §3.4.4. The Worker submits the generated Intent to the runtime through its outbox. The runtime MUST:

Verify that the Worker’s Worker Definition permits generation of the Intent kind (Intent Grammar, §3.2.5).
Verify that the Intent’s bounds fall within the bounds permitted by the Worker’s Authority Grant.
Verify that the Intent’s authority binding correctly references a clause in the Worker’s Worker Definition.
Emit an IntentGenerated event to the relevant Audit Envelope.

If verification fails, the runtime MUST refuse the generation and emit an authority-violation event. The Worker’s Driver is informed of the refusal and MAY adjust its behaviour, but MUST NOT be able to retry the action with the same parameters and succeed.

6.3 Intent Acceptance and Pursuit

An Intent in the Open state is accepted by a Worker. Acceptance binds the Worker to the Intent: the Intent moves to Accepted, the Worker assumes responsibility, and the Worker becomes the actor against whom progress is measured.

The runtime MUST select Workers for acceptance in conformance with the Intent’s target field:

If the Intent specifies a target Worker, only that Worker is eligible.
If the Intent specifies a target Worker Definition (without a specific Worker), any Worker holding the Worker Definition with capacity is eligible. Implementations MAY apply load-balancing, history-based affinity (sediment, §6.3.1), or other selection policies, provided the policy is consistent with any Compliance Profile constraints.
If the Intent specifies neither, the runtime MUST refuse the Intent (it is malformed).

Pursuit of the Intent is open-ended: the Worker invokes Capabilities, dispatches sub-Intents, queries history, escalates as needed. The runtime imposes no shape on pursuit beyond the Authority Grant. The trace of pursuit emerges in the Audit Envelope.

6.3.1 Sediment

A runtime MAY consider the receiving Worker’s history when selecting among eligible Workers for an unbound Dispatch. Examples include:

Routing follow-up correspondence to the Worker who handled prior correspondence on the same matter.
Routing periodic reviews to the Worker who performed the previous review, where continuity is valuable.

This selection bias is termed sediment. The protocol does not require sediment-aware routing, but recognises it as a legitimate organisational property and permits implementations to support it provided routing decisions are recorded in the Audit Envelope.

6.4 Dispatch

A Dispatch is the act of one Worker generating an Intent assigned to another Worker (or Worker Definition). Dispatch is not a primitive; it is the composition of Intent generation (§6.2) with a target field referring to a different Worker.

The runtime MUST, when a Dispatch is generated:

Verify that the source Worker’s Worker Definition permits dispatching the Intent kind to the target Worker Definition (Authority Grant, §3.2.4).
Verify that the target Worker Definition accepts the Intent kind (Intent Grammar, §3.2.5).
Verify that the source Worker’s bounds (cost, deadline) flow correctly to the dispatched Intent — bounds MAY be tightened on dispatch but MUST NOT be loosened.
Emit an IntentDispatched event to the Audit Envelope.

A Dispatch cannot be made to a Worker Definition outside the Function unless the Function’s Charter explicitly allows cross-Function dispatch. Cross-Workforce dispatch is permitted only via a federation mechanism specified in a companion document; it is out of scope for this draft.

6.4.1 Backpressure

Workers have capacity. A runtime MUST allow Workers to declare maximum concurrent open Intents, and MUST NOT route Dispatches to Workers at capacity. When all Workers in the eligible set are at capacity, the Dispatch is queued, and the runtime emits a DispatchQueued event. The Compliance Profile MAY constrain queue depths and waiting times.

6.4.2 Convergence

Workers MUST be tolerant of receiving Intents that are duplicative of work already in progress. A Worker SHOULD examine its open Intents before accepting a new one and MAY resolve a duplicate Dispatch with not-applicable (reason duplicate) per §6.6. The runtime MUST record these resolutions as Outcomes and MAY surface duplication patterns to Reviewers.

6.5 Escalation

Escalation is the act of a Worker handing an Intent — with full context — to a Human Role or to a Worker holding higher authority. Escalation is not a primitive; it is the composition of Intent dispatch with a target that is structurally higher in the Charter.

The runtime MUST permit Escalation only along Escalation Routes declared in the Worker’s Worker Definition (§3.2.6). Escalations attempted to Worker Definitions not in the declared Routes MUST be refused.

When an Escalation is permitted, the runtime MUST:

Pass to the receiving Worker Definition the full provenance chain of the Intent and a snapshot of the Worker’s history relevant to the Intent (such that the receiver can review the Worker’s reasoning).
Move the original Intent to the Escalated state.
Open a new Intent assigned to the receiving Worker Definition, with provenance pointing back to the original Intent.
Emit an EscalationRaised event.

The receiving Worker Definition pursues the new Intent. When that Intent is resolved, the runtime MUST propagate the resolution back to the original Intent: the original Intent is resolved with an Outcome reflecting the receiving Worker Definition’s decision, and an EscalationResolved event is emitted.

A Compliance Profile MAY require Escalation under specified conditions (e.g. all decisions above a threshold value MUST be escalated to a Human Role). When required by a Profile, the runtime MUST refuse Resolutions that would violate the Profile and surface a runtime error to the Worker, prompting the Driver to escalate instead.

6.6 Resolution

An Intent reaches resolution when the responsible party records an Outcome. The Outcome is the measured realisation of the Intent (per §3.4.1) — what actually happened, scored against the criteria the Intent declared at declaration time (§3.4.10).

Three distinct things are related here and MUST NOT be conflated (§3.4.1): the desired outcome (the Intent itself, the goal in spirit), the measurement(s) (the machine-evaluable proxies, §3.4.10), and the Outcome (the realised result — the delivered artefact(s) and the measured score). The terminal resolution kind (below) is the Intent’s state; the Outcome record is its content. Divergence among the desired outcome, the measurement score, and the delivered Outcome is surfaced as an OutcomeGapObserved signal (§3.4.12) and fed to Causal Memory (§3.7.5).

The terminal resolution kinds are enumerated in §3.4.2:

achieved — measurement criteria met. The score MUST satisfy the declared target.
not-applicable — the receiver deliberately took no action. Subsumes all “I won’t take this on” cases: cascaded Strategic Intents declined by a Workforce Director; sub-Intent dispatches declined by a Worker as duplicate, out-of-scope, infeasible, or policy-violating; any active decision not to advance the work. The receiver’s specific reason is carried as a structured reason field on the Outcome record (see below).
withdrawn — the originator cancelled (or the org acting on its behalf 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.

Escalation is not a terminal resolution. An escalated Intent is in the declared state with an additional escalated marker; resolution flows back to the original Intent per §6.5. The receiving Worker Definition’s Outcome on the escalated Intent becomes the original Intent’s Outcome.

The Outcome record MUST contain:

The terminal resolution kind (one of the four above).
A timestamp.
A signed statement by the resolving party (Worker, leadership Worker, Human Role, or — for withdrawn at higher scopes — the originator).
The measurement score — a typed object containing the result of evaluating the Intent’s measurement_criteria (§3.4.10) at resolution time. For achieved, the score MUST be present and MUST satisfy the declared target. For missed, the score MUST be present and MUST NOT satisfy the target. For not-applicable and withdrawn, the score MAY be omitted (the resolution was non-evaluative — the receiver did not attempt to advance the Intent).
A reason field — REQUIRED for not-applicable (one of duplicate | out-of-scope | infeasible | policy-violation | wrong-scope | doesnt-apply-to-workforce or implementation-defined) and withdrawn (one of superseded | cancelled-by-originator | worker-decommissioned | function-retired or implementation-defined). For achieved and missed, reason is OPTIONAL.
An optional human-readable summary.
A reference to the produced artefact, if any (e.g. an outreach proposal, a credit memorandum, a customer-facing letter).
Tradeoff narration (§3.4.11) — REQUIRED when the resolving party is a leadership Worker AND ≥ 2 Intents at the same scope were active when the Outcome was emitted. Optional otherwise.
For withdrawn resolutions due to supersession: a superseded_by: <new-intent-id> link (per §3.4.7).

For Strategic Intents (org scope), the resolving party is the Operator principal who declared the Intent, not the receiving Workforce. The runtime emits a transition-suggestion event (per §3.4.2) when conditions for achieved or missed are observed; the Operator signs the actual transition.

Upon Resolution of a top-level Intent at the Worker, Function, or Workforce scope, the runtime MUST close the Audit Envelope (§3.6.4) that the Intent rooted. Strategic Intents do not use envelopes (per §9.x); their resolution events land in the per-Authority Strategic Intent Registry.

6.7 Authority Enforcement

The runtime is the trusted enforcement boundary for the Charter.

The Charter of a Workforce, at any moment, is the union of:

All Worker Definition declarations across deployed Functions.
All Authority Grants within those Worker Definitions.
All Escalation Routes within those Worker Definitions.
All attached Compliance Profiles, each contributing additional constraints.

For every outbox action a Worker submits — Intent generation, Capability invocation, Dispatch, Escalation, Resolution — the runtime MUST evaluate the action against the Charter and permit it only if the Charter authorises it. Authorisation MUST be evaluated with the following ordering, with later layers superseding earlier ones:

Worker Definition Authority Grant.
Bounds inherited from the Intent under which the action is taken.
Constraints from any attached Compliance Profile.

Where layers conflict, the most restrictive applies. Authority not explicitly granted is implicitly denied.

When an action is refused, the runtime MUST emit an authority-violation event and MUST inform the Worker’s Driver. The runtime MUST NOT silently drop the attempted action; refusal is an observable event.

6.8 Cascade Decomposition

A leadership Worker (§3.2.7) receives an upstream Intent at the scope above its own (an org-scope Strategic Intent reaching a Workforce Director Worker, or a workforce-scope tactical Intent reaching a Function Lead Worker). The Worker’s Driver MUST invoke the cascade decomposition path:

Render the decomposition prompt. The Driver fills the Charter’s decomposition_grammar.prompt_template with the upstream Intent’s payload, measurement criteria, and any KBs referenced by the prompt template.
Invoke the LLM Capability. The Driver invokes the bound LLM Capability with structured-output enabled, requesting output conformant to decomposition_grammar.required_decomposition_output_schema.
Validate the structured output. The runtime MUST validate the LLM response against the declared schema. Invalid output MUST be refused; the Driver MAY retry with the validation failure as additional context.
Emit decomposed Intents. For each downstream Intent in the validated output, the runtime emits an Intent declaration:
- scope is the next level down (workforce Director emits workforce Intents; function Lead emits function Intents).
- target_role MUST be one of the leadership Worker Definition’s decomposition_grammar.target_roles.
- kind MUST be one of the leadership Worker Definition’s decomposition_grammar.target_kinds.
- Provenance is cascade-originated (for inherited cascades) or strategic-cascade-originated (when the upstream is a Strategic Intent in the registry) — see §3.4.5.
Emit a resolution on the upstream Intent. Once the downstream Intents are declared, the leadership Worker MUST resolve the upstream Intent. Typical resolutions: not-applicable (if no downstream work is warranted), or — when the upstream is being treated as a parent for cascade tracking — the upstream remains declared and the leadership Worker tracks realisation by aggregation (§6.9). The Charter’s decomposition_grammar specifies which model applies.

The runtime MUST cache the decomposition output keyed by the upstream Intent ID. Leadership Workers MUST NOT re-reason on every Signal — re-reasoning is triggered only by upstream Intent declaration, supersession (§3.4.7), or amendment-by-supersession. This is a hard requirement to prevent the cascade’s reasoning cost from scaling linearly with operational throughput.

6.9 Outcome Aggregation

A leadership Worker MUST emit aggregated Outcomes on the cadence declared in its Charter’s aggregation_grammar.emission_cadence (§3.2.7). The aggregation path:

Collect downstream Outcomes. The runtime supplies Outcomes from the Worker Definitions in aggregation_grammar.source_roles, filtered to those that resolve against the upstream Intent the leadership Worker is tracking.
Render the aggregation prompt. The Driver fills aggregation_grammar.prompt_template with the collected Outcomes, the upstream Intent’s measurement criteria, and any referenced KBs.
Invoke the LLM Capability. Structured output conformant to aggregation_grammar.output_measurement_schema.
Validate and emit. The aggregated Outcome MUST satisfy the upstream Intent’s measurement_criteria schema (§3.4.10). If requires_tradeoff_narration is true and ≥ 2 Intents at the scope are active, the Outcome MUST include tradeoff_narration (§3.4.11) or the runtime MUST emit TradeoffNarrationOmissionDetected.
Report upward. For Workforce Directors, the aggregated Outcome is reported into the Strategic Intent Registry as a WorkforceAggregatedOutcomeReported event (§9.1, §9.6). For Function Leads, the aggregated Outcome is reported into the Workforce Director’s input set on its next aggregation cycle.

Aggregation is continuous narration, not just terminal scoring. Leadership Workers MUST emit aggregated Outcomes at interim cadence (weekly or monthly per Charter declaration) AND at on-intent-resolution. This is a hard requirement so slow strategic feedback loops surface tradeoffs early.

6.10 Transition Suggestion Emission

For Intents at the org, workforce, and function scopes that declare TTL or measurement criteria, the runtime MUST NOT auto-apply terminal-state transitions. Instead:

The runtime continuously evaluates the Intent’s measurement_criteria (§3.4.10) at the leadership Worker Definition’s emission_cadence and at TTL boundaries.
When evaluation reaches the achieved threshold or the TTL expires without achievement, the runtime emits a transition-suggestion event — StrategicIntentTransitionSuggested for org-scope Intents (into the registry), or the scope-appropriate equivalent for workforce/function-scope Intents (into the relevant envelope).
The suggestion event carries the proposed terminal state (achieved | missed), the evaluation evidence (the resolved criterion result + supporting Outcomes / Signals), and addresses the originator.
The originator MUST sign the actual transition for it to take effect. The runtime emits a *Transitioned event signed by the originator.

For worker-scope Intents, the existing OWP-2 model applies: the responsible Worker (or escalation recipient) resolves directly. No suggestion-then-sign path; the resolving party signs the Outcome inline.

6.11 Leadership Worker Definition Enforcement at Function Bundle Load

The Function Loader (§4.1.4) MUST enforce the mandatory-presence invariant from §3.2.7:

For every Workforce in the Function bundle’s declared deployment: exactly one Worker Definition of kind role-kind:leadership/workforce-director with scope: workforce.
For every Function in the bundle: exactly one Worker Definition of kind role-kind:leadership/function-lead with scope: function.

Function bundles that fail this check MUST be refused at instantiation. The runtime MUST emit a FunctionBundleLoadRefused event carrying the specific invariant violation. The Operator commissioning the deployment MUST see the refusal with an actionable error.

The runtime MUST additionally validate at load time:

Each leadership Worker Definition’s scope value matches the structural location of the Worker Definition (a role-kind:leadership/workforce-director declared inside a Function — rather than at the Workforce level — is malformed).
Each leadership Worker Definition’s decomposition_grammar.target_roles references only Worker Definitions that exist in the bundle.
Each leadership Worker Definition’s decomposition_grammar.target_kinds is a subset of the Worker Definition’s Intent Grammar issues clause (§3.2.5).
Each leadership Worker Definition’s aggregation_grammar.source_roles references only Worker Definitions that exist in the bundle at the appropriate scope.

Succession is handled as an atomic Recalibration per §3.2.7. The Function Loader MUST refuse Recalibrations that would transiently violate the mandatory-presence invariant.

6.12 Allocation Deliberation

Cascade decomposition (§6.8) presumes the Workforce Director knows which Function should own a piece of work. When more than one Function could plausibly own it, the Director needs what each Function’s Lead knows — current roster capability, live capacity, calibrated confidence — before deciding. Allocation Deliberation is the audited protocol for gathering exactly that. It preserves the single-decision-point invariant of §3.2.7: bids are advisory inputs; the award is the Director’s alone. Detailed design rationale appears in ADR-W20 in the companion repository.

6.12.1 Trigger order

When a workforce-scope Intent reaches the Workforce Director, the runtime MUST resolve its allocation in this order, taking the first that applies:

Explicit target. The Intent names a target Worker or Worker Definition (§3.4.4): §6.3 target resolution applies unchanged. No deliberation.
Live weighted route. A weighted route (§6.12.5) exists for the Intent’s shape with weight at or above the re-deliberation threshold: the Director decomposes down the routed path per §6.8, and the runtime MUST record in the Audit Envelope that the route was used, together with the route’s weight at time of use. No deliberation.
Deliberation. Otherwise, the runtime MUST run a deliberation round (§6.12.2–§6.12.4).

Deliberation is the exception path: routine work never pays its cost; novel work pays it once, and again only when the sedimented answer has stopped being trustworthy.

6.12.2 Solicitation

The runtime, acting for the Director, opens the round by emitting an AllocationSolicited event (signed by the Director) carrying the candidate Lead set and the assessment TTL, and fans out one assessment Intent to each candidate Function Lead:

The assessment Intent is of the protocol-defined kind intent:owp:allocation-assess/v1, at worker scope, with a TTL equal to the declared assessment bound.
Assessment Intents are ordinary Intents: they are dispatched through §6.4 (authority-gated, backpressure-aware per §6.4.1), inherit the top-level Intent’s Audit Envelope per §3.6.2, and resolve through §6.6.
Every conformant Function Lead Worker Definition implicitly accepts intent:owp:allocation-assess/v1; an implementation MAY additionally require its explicit declaration in the Intent Grammar.

Leads assess independently. The runtime MUST NOT disclose one Lead’s bid to another during the round. The protocol defines no clarification or negotiation exchange: a solicitation is one round, and a Director requiring more information than the bids provide escalates (§6.12.4) rather than conversing.

6.12.3 Assessment and bids

The bid is the measured Outcome of the assessment Intent, signed by the assessing Lead like any Outcome. A bid resolving achieved MUST carry a structured assessment containing at minimum:

capability match — the Lead’s judgement of fit against its roster’s Worker Definitions (which Definitions could take the work, and why);
capacity — the Function’s open-Intent load against declared ceilings. The runtime MUST supply the ground-truth figures; the Lead narrates over them and MUST NOT invent them;
confidence — the Lead’s calibrated estimate that the Function would achieve the Intent’s measurement criteria;
cost estimate — bounded by the Function’s declared cost ceilings.

The runtime MUST validate the assessment structure (the §6.8 structured-output precedent) and MUST refuse structurally invalid bids; the Lead’s Driver MAY retry within the TTL.

Individual Workers do not bid; the Function Lead assesses on behalf of its Function by narrating over the runtime-supplied roster facts — each Worker’s declared Capacity (§3.2.9), live open-Intent load, and Competency Profile (§3.2.8). A Human Worker (§3.2.12, execution: human) contributes these facts exactly as an AI Worker does: it is roster ground truth the Lead reads, declared once at charter time, never a live response inside the assessment window. A Human Worker’s presence in a Function therefore does not change deliberation timing — the Lead’s bid remains a bounded, synchronous act. A Function MAY be awarded work its Lead intends to route to a Human Worker; that routing happens at §6.8 dispatch time inside the winning Function, where the Human Worker’s accept-TTL (§3.4.2) governs.

Refusal is a first-class answer: a Lead declines by resolving the assessment Intent not-applicable with a structured reason (§6.6). Non-response by TTL resolves missed and is treated as refusal. Both are signed, auditable positions.

6.12.4 The award

The Director evaluates the bids and emits an AllocationAwarded event, signed by the Director, carrying the chosen Function, the recorded reasoning, and references to every bid Outcome — winning and losing. The award then feeds the ordinary §6.8 cascade decomposition targeting the winning Function’s Lead; deliberation changes what the Director knows, not who decides or how work flows afterwards. Ties are broken by the Director’s judgement; the recorded reasoning is the accountability surface for that judgement.

If every candidate Lead refuses, the Director MUST NOT force an award. The runtime escalates the Intent per §6.5 (typically to the Operator): unanimous refusal is a signal that the Workforce is mis-scoped and MUST surface rather than be absorbed. If no active Director exists, the mandatory-presence invariant (§3.2.7, §6.11) has been violated and the deployment is at fault; Intents queue until a Director is active.

6.12.5 Weighted routes

A completed award sediments into a weighted route: an association from an Intent shape to a Function, carrying a numeric weight. Routes are learned runtime state — never Charter content, never directly authored or edited (the learned-state posture of §3.7’s Memory dynamics applies). The runtime MUST:

emit a signed RouteSedimented event when an award creates or refreshes a route;
route subsequent matching Intents directly (trigger order tier 2) while the weight is at or above the re-deliberation threshold, recording each use per §6.12.1;
reinforce the route’s weight when an Intent it routed resolves achieved against its measurement criteria, and decay it on missed or not-applicable — the signal arriving through the §6.9 aggregation flow;
emit a signed RouteWeightAdjusted event for every weight change, carrying the cause (outcome-feedback | roster-change | recalibration | deployment);
stop short-circuiting when the weight falls below the re-deliberation threshold: the next matching Intent deliberates afresh.

This mirrors the reinforce/decay dynamics of Causal Memory (§3.7.5): an allocation is a belief about where work belongs, hardened by measured success and weakened by measured failure. A wrong award is thereby self-limiting — it fails measurably, the failures decay the route, and the question is re-asked.

6.12.6 Invalidation

The runtime MUST invalidate affected routes — emitting a signed RouteInvalidated event with cause — on:

roster change in a candidate Function: a Worker Instance added, decommissioned (§12.5), or re-bound (WorkerInstanceRebound, §3.1.7);
Charter recalibration (§12.4) of a Worker Definition in a candidate Function;
Function deployment or retirement in the Workforce;
weight demotion below the re-deliberation threshold (§6.12.5).

After invalidation, the next matching Intent re-deliberates — and may land elsewhere, because the answers to “who can best do this?” have changed. This property is the point of the mechanism: the workflow is not authored; it is re-derived from the current team whenever the team changes, with the full derivation on the audit record.

6.12.7 Audit shape

All deliberation artefacts live in the top-level Intent’s Audit Envelope (§3.6.2) and are signed by exactly one actor each, per §9.2 — the protocol requires no multi-actor co-signing:

Artefact	Event	Signer
Solicitation (candidate set, TTL)	`AllocationSolicited`	Workforce Director
Each bid or refusal	the assessment Intent’s ordinary lifecycle and resolution events	that Function Lead
Award (reasoning + all bid references)	`AllocationAwarded`	Workforce Director
Route created / adjusted / invalidated	`RouteSedimented` / `RouteWeightAdjusted` / `RouteInvalidated`	runtime

An auditor can answer, from one envelope: who was asked, what each said, who decided, on what stated reasoning — and, across envelopes, how that decision’s weight evolved as measured reality arrived.