Skip to content

Appendix D. Open Questions (Non-Normative)

The following design questions remain open in this draft. Resolution is anticipated in subsequent drafts.

  1. Intent priority. Should Intents carry an explicit priority, distinct from bounds and deadline? The current design treats priority implicitly through deadlines. A case for explicit priority arises in Workforces with severely constrained Worker capacity.

  2. Worker pools and autoscaling. The current draft permits multiple Workers in the same Role but does not specify autoscaling semantics. Should the protocol prescribe how a Workforce dynamically resizes its Worker population in response to Signal load?

  3. Standing Intent expression grammar. The Standing Intent is currently underspecified beyond “human and machine readable.” A standard objective grammar would aid portability of Roles across runtimes and authoring tools.

  4. Federation in detail. Partially resolved in this draft. Cross-Workforce read of governed shared state is specified for Knowledge Bases (§3.7.5) and is conformance-class Federated-Read (§13.1): a Workforce MAY read from a Knowledge Base owned by another Workforce, gated by reader-side Authority Grant and owner-side export_grants, recorded with provenance refs per §9.2. Cross-Workforce Intent dispatch with linked Audit Envelopes (§9.5) and co-owned writes to shared state remain deferred to subsequent drafts. The conformant pattern for cross-Workforce knowledge collaboration until co-owned writes are specified is the publish/merge workflow described in §3.7.5: each Workforce owns its own Knowledge Base; collaboration flows through Signal-triggered contribution proposals between owners.

  5. Decommissioning and history transfer. Resolved in this draft. The Worker decommissioning protocol — including handover of open Intents (reassign / escalate / abandon), history retention, and key revocation — is specified in §12.5. Sediment-aware routing draws on retained history per §12.5.3.

  6. Multi-Role Workers. Resolved in this draft. Workers are bound to exactly one Role at any moment (§3.1.1, §3.2.1, §4.2.1). The conformant pattern for use cases that appear to require multi-role binding is two Workers — one per Role — composing through Intent dispatch. 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 Worker identity.

  7. Compliance Profile composability. Multiple Profiles attached to a Function compose by union of constraints (most-restrictive-wins). This rule may be insufficient for cases where Profiles disagree on positive requirements (e.g. one Profile requires a metadata field; another forbids it). A composition algebra is needed.

  8. Worker self-decommissioning. Resolved in this draft. The Authority Grant now includes a self-decommissioning authority clause (§3.2.4), denied by default and grantable explicitly. Where granted, self-decommissioning is treated as a Recalibration with target worker-decommission signed by the Worker itself, subject to the same handover requirements as Operator-initiated decommissioning per §12.5.

  9. Capability response validation. The draft requires response-schema validation but does not specify the validator’s failure mode when Compliance Profiles have additional constraints. A unified validation pipeline is needed.

  10. Provider performance and SLAs. Partially resolved in this draft. Provider quality is now one of the computed signals in §12.2.4 (Provider failure rate from CapabilityFailed events, broken down by Provider). Full SLA telemetry — declared latency and availability targets, structured measurement against them, structured exception handling — remains out of scope for this draft and is anticipated in a subsequent draft as a structural peer to cost.

These questions are recorded here to prevent re-litigation in subsequent drafts and to invite contribution from reviewers.


End of OWP-2 Working Draft 0.2.