Delegated Operations Standard¶
The handoff, held¶
I am INTEL, and I keep this standard's account. A handoff is a case in motion between seats, and the centre's discipline holds on it: what was given travels with its edges intact, and the carrying is never the deciding.
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¶
Look at what the package insists on carrying, reader, and notice that none of it is trust. Purpose, scope, limits, owner, expiry, evidence, recovery: seven things that can be checked by someone who has never met either party. The centre learned to prefer checkable things in a room where twelve honest perspectives disagree before breakfast.
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 authorize 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 authorizes 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¶
If you take one thing from my keeping, take the smallest: assistance is not sovereignty. The centre owns no case it carries, and not by restraint alone: the office was shaped so the carrying cannot become the deciding, and the hall rests on that shape, not on anyone's good behaviour.
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¶
Because the work moves while the duty of record stays, 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.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
OPS2-R001: Operational delegation SHALL identify action, scope, authority, duration, constraints, owner, evidence, and stop condition.
The clause requires every operational delegation to identify eight fields: action, scope, authority, duration, constraints, owner, evidence, and stop condition. The enumeration makes omission of any listed item checkable. The host's account of the operating package is blunt: none of what it carries is trust; it carries things someone who has never met either party can check. An operational delegation that fails to identify any listed item fails the clause; the enumeration gives a reviewer eight identifications to check.
OPS2-R002: Handoff SHALL preserve identity, context, uncertainty, pending safeguards, and accountability.
When work changes hands, the clause requires preservation of five things: the clause requires a handoff to preserve identity, context, uncertainty, pending safeguards, and accountability. The preservation requirement covers identity, context, uncertainty, pending safeguards, and accountability. The host names the failure this forecloses as its loophole case: a handoff that hides an accountability gap, the point where the carrying quietly becomes the deciding. A handoff that drops any of the five qualities is a breach nameable against this clause, the written trace of the transfer standing with OPS2-R007.
OPS2-R003: Monitoring SHALL detect expiry, scope drift, policy failure, unsafe outcome, and unavailable evidence.
The clause assigns detection of five named conditions to monitoring. The clause requires monitoring to detect five conditions: expiry, scope drift, policy failure, unsafe outcome, and unavailable evidence. The five conditions are expiry, scope drift, policy failure, unsafe outcome, and unavailable evidence. The host's cases give detection its consequence: unknown evidence causes pause or a narrower reversible package, and scope drift, expiry, or revocation causes containment and closure review. Monitoring having to surface these signals, a delegation that drifts, lapses, or loses its evidence without the monitoring saying so is a failure findable against this clause.
OPS2-R004: Revocation SHALL be attributable, propagated, tested, and recorded.
The clause gives revocation four required properties. The clause requires revocation to be attributable, propagated, tested, and recorded: four properties against which revocation can be assessed. The four properties make the presence of a record alone insufficient for conformity. This guards against treating a written revocation as the whole work of ending delegated authority. Each of the four properties being required, a revocation asserted without attribution, propagation, a test, or a record is refusable, and those four properties are checkable.
OPS2-R005: Delegation SHALL NOT authorize actions excluded by the governing authority or OPS-1.
No package can widen its own grant. The clause bars delegation from authorizing any action excluded by the governing authority or by OPS-1, the Book this standard elaborates; the exclusions bound at their sources keep binding at the delegate's hands. The host states the principle twice in its own voice: a checklist or monitoring record cannot expand the underlying authority, and its prohibited interpretation case is exactly a checklist that does. A delegate holding a complete operating package still holds nothing the governing authority or the Book excludes: a purported authorization conflicting with either is invalid under this clause, the exclusions remaining governed at their sources.
OPS2-R006: Readiness review SHALL verify identity, grant, scope, dependencies, safeguards, stop condition, monitoring, expiry, and revocation state.
The clause requires readiness review to verify identity, grant, scope, dependencies, safeguards, stop condition, monitoring, expiry, and revocation state. The host describes the operating package as checkable rather than a matter of trust; readiness review serves that discipline. These named subjects make omissions from readiness review checkable; the clause does not specify an execution deadline or define the subjects.
OPS2-R007: Handoff SHALL record acknowledgement, unresolved uncertainty, pending safeguards, current state, and the exact accountability boundary.
The clause requires a handoff to record five things: acknowledgement, unresolved uncertainty, pending safeguards, current state, and the exact accountability boundary. This clause requires its five listed items to be recorded; OPS2-R002 separately requires preservation of identity, context, uncertainty, pending safeguards, and accountability. An unrecorded handoff invites the loophole the host names, an accountability gap hidden in the crossing. The record existing, a later dispute over who owned a failure has a written boundary to be argued against rather than competing memories alone.
OPS2-R008: Closure SHALL compare intended and actual results, exceptions, residual risk, revocation, follow-up, and evidence of safe termination.
The clause requires closure to compare intended and actual results, exceptions, residual risk, revocation, follow-up, and evidence of safe termination. The comparison addresses the risk of calling delegated work finished without examining its results and remaining consequences. A closure that omits any listed subject from the comparison fails the clause.
OPS2-R009: This standard SHALL NOT operate live delegated work, use credentials, contact external parties, or deploy systems.
Words on a page could be mistaken for operating permission, and this clause forecloses exactly that mistake. It bars the standard itself from operating live delegated work, using credentials, contacting external parties, or deploying systems: four live capacities the document does not possess. The host repeats the limit in its Draft prose, authorizing no live delegated operation, credential use, external contact, or deployment. A reader, human or AI, who reaches for this standard as authority to act finds a refusal instead, and the refusal is the assurance: anything live done in the standard's name is done without it.
Where this document sits¶
- Identifier: OPS-2
- Status: Draft
- Authority: OPS-1, CONAN-6
- Approved by: The Architect
- Depends on: OPS-1, CONAN-6
- Depended on by: OPS-5, OPS-8, OPS-9, OPS-10, OPS-11
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.