Skip to content

Delegated Operations Standard

Why this chapter matters

Delegated work is where trust becomes operational. This standard makes the handoff visible: purpose, scope, limits, owner, expiry, evidence, and recovery remain attached to the task so neither a human nor an AI can mistake assistance for sovereignty.

Continue to the Human Approval Control Matrix to see where human judgement must remain explicit.

Purpose

This standard translates a valid delegation into an accountable operating package. It is concerned with readiness, handoff, monitoring, pause, revocation, and closure, not with granting authority itself.

Operating package

Before execution, the package should identify the request, operation, acting identity, delegation record, scope, constraints, dependencies, evidence baseline, affected parties, stop conditions, escalation route, expiry, and reviewer. The executor should confirm that the package is current and refuse work where a required field is unknown or contradictory.

  • OPS2-R001: Operational delegation SHALL identify action, scope, authority, duration, constraints, owner, evidence, and stop condition.
  • OPS2-R002: Handoff SHALL preserve identity, context, uncertainty, pending safeguards, and accountability.
  • OPS2-R003: Monitoring SHALL detect expiry, scope drift, policy failure, unsafe outcome, and unavailable evidence.
  • OPS2-R004: Revocation SHALL be attributable, propagated, tested, and recorded.
  • OPS2-R005: Delegation SHALL not authorise actions excluded by the governing authority or OPS-1.
  • OPS2-R006: Readiness review SHALL verify identity, grant, scope, dependencies, safeguards, stop condition, monitoring, expiry, and revocation state.
  • OPS2-R007: Handoff SHALL record acknowledgement, unresolved uncertainty, pending safeguards, current state, and the exact accountability boundary.
  • OPS2-R008: Closure SHALL compare intended and actual results, exceptions, residual risk, revocation, follow-up, and evidence of safe termination.
  • OPS2-R009: This standard SHALL NOT operate live delegated work, use credentials, contact external parties, or deploy systems.

Handoff and closure

Handoff should be attributable and acknowledged. It should carry pending safeguards, unresolved uncertainty, current state, evidence gaps, and the exact point at which responsibility changes. Monitoring should produce reviewable signals and should pause or escalate when scope, authority, evidence, safety, or dependency assumptions change. Closure should record intended versus actual result, exceptions, residual risk, revocation status, and follow-up.

This Draft authorises no live delegated operation, credential use, external contact, or deployment. A checklist or monitoring record cannot expand the underlying authority.

Operating model and interpretation cases

Delegated operations review turns a valid grant into a bounded readiness, handoff, monitoring, pause, revocation, and closure package. It checks that the executor can identify the grant, current state, dependencies, stop condition, and review route. Handoff preserves accountability and does not silently transfer authority.

  • Conforming: Grant, identity, handoff, safeguards, monitoring, expiry, revocation, result, and residual risk are linked.
  • Prohibited: A checklist expands the underlying delegation.
  • Boundary: Unknown evidence causes pause or a narrower reversible package.
  • Failure: Scope drift, expiry, or revocation causes containment and closure review.
  • Loophole: Handoff or monitoring hides an accountability gap.
  • Misuse: Operating records expose credentials or private parties.
  • Care-control: Delegated support remains proportionate, reviewable, and restorable.

Design evidence

Delegated-operation review should reconcile the grant, acting identity, handoff acknowledgement, pending safeguards, monitoring signals, expiry, revocation propagation, stop condition, actual result, and residual risk. A handoff preserves accountability rather than transferring authority implicitly.