Skip to content
OWP

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 Roles subscribe to the Signal’s kind, subject to any subscription filters declared in the Role.

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 Role 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 Role.
  • 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 Role (without a specific Worker), any Worker holding the Role 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 Role). 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 Role permits dispatching the Intent kind to the target Role (Authority Grant, §3.2.4).
  • Verify that the target Role 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 Role 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 refuse a Dispatch as duplicate (a sub-state of refused) where appropriate. The runtime MUST record refusals 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 Role (§3.2.6). Escalations attempted to Roles not in the declared Routes MUST be refused.

When an Escalation is permitted, the runtime MUST:

  • Pass to the receiving Role 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 Role, with provenance pointing back to the original Intent.
  • Emit an EscalationRaised event.

The receiving Role 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 Role’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 Worker (or escalation recipient) records an Outcome. The Outcome is one of:

  • achieved — the Intent’s purpose was fulfilled.
  • refused — the Intent was rejected, with a reason. Refusal sub-states include duplicate, out-of-scope, policy-violation, and infeasible. Implementations MAY define additional sub-states; sub-states MUST be machine-distinguishable.
  • escalated — the responsible Worker escalated; the Intent is in the Escalated state pending resolution by the escalation recipient.
  • abandoned — the Intent was not pursued to completion (e.g. timeout, deadline elapsed, Worker decommissioned). Abandonment is recorded as a reason on the Outcome.

The Outcome record MUST contain:

  • The terminal state.
  • A timestamp.
  • A signed statement by the resolving Worker (or Human Role).
  • 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).

Upon Resolution of a top-level Intent, the runtime MUST close the Audit Envelope (§3.6.4).

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 Role declarations across deployed Functions.
  • All Authority Grants within those Roles.
  • All Escalation Routes within those Roles.
  • 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:

  1. Role Authority Grant.
  2. Bounds inherited from the Intent under which the action is taken.
  3. 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.