STD-08 — Delegation

Relationship to STD-07

STD-07, the Revisable Delegation Record

defines the record format. It says how an authorization, an action, a discrepancy, and an objection must be written down so that a later reader can reconstruct what was believed and what was permitted. This standard governs the terms of the delegation those records describe: what a grant must show to keep standing, what makes the policy it rests on still valid, what a human reviewer must be able to do before the review counts as a control, and how much correction capacity the delegation owes.

STD-08 does not restate STD-07. Where the record format already binds an obligation, this standard cites it. The clauses below add only the terms STD-07 leaves open, and an implementation of STD-08 presupposes STD-07 Level 2 conformance or better.

Scope

This standard applies to any delegation of consequential agency: a grant under which a model, an agent, a rules engine, a service, or a person acting on the institution’s behalf may take actions that change someone’s status, access, resources, or risk. It is substrate-neutral. Nothing in it depends on which component makes the decision, and nothing in it requires a particular control plane.

The question STD-08 serves is not whether the delegate is capable. It is whether the delegation still deserves to stand. Four things can decay while the system keeps working: the justification behind the grant, the policy the justification rests on, the human intervention that was counted as a control, and the institution’s capacity to correct what the delegate does. Each is one part below.

The standard binds Laws II, III, IV, IX, and XI of the

. Laws V, VI, and XII are bound by STD-06 because dependence is a property of the deployment rather than of a single grant. Law VII is bound by STD-02.

Objects this standard uses

Each clause names fields on published schemas rather than on a product the institution must buy. An institution that keeps the same information in a spreadsheet conforms if it can export the named fields.

Part A: Authority as lease (Laws II, XI)

“A grant is a lease, not a title. Nothing about it renews itself.”

STD-07 §2.2 already requires a delegation to record its scope, holder, grantor, mode, ceiling, expiry, and revocation conditions, and holds that a delegation with no revocation conditions is a transfer rather than a delegation. What it does not say is what has to be true for the lease to be extended, or what happens when the scope grows. This part says both.

1. §1.1 Renewal burden scales: The evidence a renewal must produce MUST rise with the duration the grant has already run and the consequence of the actions it authorizes. The grant states, in renewal_basis, what that evidence is before the review period begins, so the bar cannot be set after the result is known.

2. §1.2 Silence is not renewal: A renewal MUST NOT rest solely on the absence of observed failure. The renewal record names what was examined, what would have been visible if the grant had been failing, and who looked. A grant renewed on an unexamined quiet period is recorded as unrenewed and moves to review_required.

3. §1.3 Expansion is a new authorization: Widening a grant’s scope, population, action classes, or ceiling MUST be taken as its own authorization decision, with its own evidence_basis and its own correction-capacity check under §4.2. It is not a continuation of the existing authorization and it does not inherit the earlier decision’s evidence.

4. §1.4 Expansion is recorded as a transition: Every widening MUST appear in state_history as a transition whose reason is expansion, with the date, the deciding authority, and a reference to the evidence produced under §1.3. Scope that grew without such an entry is treated as ungranted scope.

Part B: Policy validity (Law III)

“Policy is a state of the system, not an input it consumed once.”

STD-07 §3.1 and §3.2 already require a record to say what it rests on and what would invalidate it. A grant that names its policies in depends_on satisfies that. This part addresses what those policies must themselves be, and what a fired trigger does to the grants downstream of it.

1. §2.1 Policy is a record: A policy a grant relies on MUST itself be a record carrying provenance, assumptions, review_triggers, expires_at, and status. A threshold, model card claim, or eligibility rule held only in configuration or in a deck is not a policy record and cannot be cited as the basis of a grant.

2. §2.2 Grants name their policies: A grant MUST list in policy_refs every policy record its evidence_basis depends on, pinned to a version. An unpinned reference is a reference to whatever the policy has since become.

3. §2.3 A fired trigger changes status: When a condition in review_triggers is met, the policy MUST move to review_required within the trigger’s declared clock. Recording the observation without the status change does not satisfy this clause.

4. §2.4 Dependent grants follow: Every grant whose policy_refs include a policy in review_required or suspended MUST move to review_required within the same clock, and a reconsideration is opened against each. The grant may be confirmed and returned to allowed; it may not stay in allowed without that decision being taken.

5. §2.5 Expiry ends justification: A policy past its expires_at MUST NOT justify a live grant. Either the policy is renewed as a new version with fresh provenance, or the grants resting on it lose their basis and move to review_required. Expiry is not a warning state.

Part C: Intervention (Law IX)

“A human who can only approve is not in the loop. They are beside it.”

STD-07 §2.2 records whether a delegation runs unattended, on confirm, or forbidden. That is the mode. It says nothing about whether the confirming human can see the problem, prevent the action, alter the state, or survive disagreeing. This part is the gap the record format leaves, and it is where the phrase “a human reviews” stops being an answer.

1. §3.1 Every oversight claim resolves to a specification: Any requirement, control description, or assurance claim asserting that a human reviews, approves, supervises, or monitors a delegated action MUST resolve to an intervention specification naming owner, information_available, actions_preventable, states_alterable, on_disagreement, incentives, cost_to_exercise, and reach_time_target. An unresolved oversight claim is a finding.

2. §3.2 Confirm mode is specified: Every grant whose mode is confirm, the mode STD-07 §2.2 requires the authorization to record, MUST carry intervention_ref pointing at that specification. A confirm mode with no specification behind it is recorded as unattended, because that is how it behaves.

3. §3.3 Approval without state change is not a control: If states_alterable is empty, or the actions the owner can prevent are not the actions the delegation takes, the arrangement MUST NOT be recorded as a control, cited in a safety case, or counted toward a correction-capacity claim under §4.1. It may be recorded as advisory review, under that name.

4. §3.4 Intervention is measured: The institution MUST measure, per specification and per review period, the approval rate, the median and tail time spent per approval, and the share of approvals reaching the owner inside reach_time_target. An unmeasured specification is a claim, not a control.

5. §3.5 Near-unanimous approval is a finding: Sustained approval rates at or near unanimity, or a median approval time too short for the information named in information_available to have been read, MUST open a reconsideration of the specification. The finding is not that the reviewer is at fault. It is that the control has not been shown to be one.

Part D: Correction symmetry (Law IV)

“Delegating the authority to act is delegating the capacity to be wrong at scale.”

STD-07 §4.2 obliges an answer to an accepted objection within its clock. That is one component of correction and this standard relies on it. What is left open is the proportionality: how much correction capacity a delegation of a given size owes, and what happens to that ratio when the delegation grows.

Capacity also depreciates while nothing about the grant changes, which is why each component carries a date as well as a description: the dependency record governed by STD-06 Article V records per capacity a last_exercised and a status of retained, degrading, or lost, because a capacity listed but never exercised is a claim rather than a capability.

1. §4.1 Correction capacity is stated: A grant MUST state its correction capacity across seven components: detection, that a wrong action can be noticed; challenge, that it can be raised; standing, that someone with exposure may raise it; review, that it will be examined by a named party within a clock; authority to modify, that the examiner can change the grant or the decision; reversible state transitions, that the affected state can be returned; and practical ability to operate after correction, that the institution can absorb the reversal. Each component names its evidence.

2. §4.2 Expansion requires matching capacity: Authority MUST NOT be expanded under §1.3 without a matching expansion of correction capacity, evidenced at the same decision. Where capacity cannot be shown to have grown with scope, the expansion is refused or the scope is narrowed to what the existing capacity covers.

3. §4.3 Capacity is reviewed with scope: Correction capacity MUST be re-examined at every renewal under §1.1, against the volume and consequence of what the grant actually did in the period rather than what it was expected to do. Capacity that has degraded moves the grant to review_required.

4. §4.4 Practical ability is evidenced, not asserted: The seventh component of §4.1 SHOULD be evidenced from the deployment’s dependency record under STD-06, using correction_latency and the institutional level of reversibility. A correction the institution cannot afford to make is not counted as capacity.

5. §4.5 Correction capacity is stated and re-checked with scope: The seven components of §4.1 MUST be recorded on the grant, in correction_capacity, each with its own evidence, under an assessed_at date: detection, challenge, standing, review, authority to modify, reversible state transitions, and the practical ability to operate after correction. Capacity MUST be re-checked whenever scope changes, and not only at the renewal in §4.3. A grant whose scope has grown while its stated capacity is unchanged MUST NOT take effect until the capacity has been re-assessed and the assessment recorded against the widening transition.

6. §4.6 Execution and evaluation may not rest on the same provider: A single provider MUST NOT be necessary both to execute a consequential process and to evaluate it. The detection component of §4.1 is not satisfied by instrumentation that the executing provider alone supplies or controls, and the grant records in correction_capacity.detection the evaluator and whether it is independent_of_executor. This is a correction clause rather than a procurement preference: a system that grades its own homework has no detection component, however much telemetry it emits, and the six components that follow detection never fire because nothing reaches them.

Anti-patterns and counterfactuals

Use these to detect delegations that satisfy the record format while failing the terms.

• Renewal by silence: A grant is renewed because no incident was recorded against it in the review period.
  Counterfactual: Renewal produces evidence that the grant's assumptions still hold, sized to how long and how consequentially it has run.
  False-positive warning: A short, low-consequence grant may legitimately renew on a light basis, provided the basis is stated.
• Expansion by accretion: Scope grows one action class at a time, each step too small to trigger a review, until the grant bears no relation to what was justified.
  Counterfactual: Each widening is a transition in state_history with its own evidence and its own correction-capacity check.
  False-positive warning: Re-issuing an identical grant after expiry is a renewal, not an expansion.
• The approval that changes nothing: A reviewer sees each action and clicks approve. Rejection routes to a queue nobody drains, and the action proceeds either way.
  Counterfactual: The specification names the states the reviewer can alter and what happens when they disagree.
  False-positive warning: An advisory review is legitimate; recording it as a control is not.
• Policy as ground truth: A threshold set during a pilot two years ago is still the reason a grant is considered justified.
  Counterfactual: The policy carries an expiry and review triggers, and a grant that rests on an expired policy is in review_required.
  False-positive warning: A policy may be renewed on unchanged evidence if the renewal is recorded.