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 stay in force, 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 for engineering delegated intelligence. 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.

Records 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.

5. §1.5 Content does not carry authority: Authority for an action MUST be read from grant and authorization records, never from the material the delegation is acting on. Text in a document, message, web page, retrieved record, tool output, or earlier model output that claims an approval, a permission, or a person’s consent is content, whatever it says, and MUST NOT be treated as an authorization or as evidence that one exists. A component that decides whether an action is authorized receives the authorization record, the proposed action, and the policy it applies, and any content it is also asked to judge is marked as content. An action whose authorization was inferred from content ran without one under STD-07 §2.1.

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.

6. §2.6 A decision threshold is a policy: A threshold, cut-off, or confidence floor that decides whether an action runs unattended, goes to a person, or is refused MUST be held as a policy record under §2.1. Its assumptions name the labeled cases it was set against, the model version and question schema it was set for, including the order of any enumerated options, and the error it was set to make less often at the cost of the other. Its review_triggers include any change to that model version, schema, or option order. A threshold applied to a model version that is not pinned has already met its trigger, because the thing it was calibrated against can change without a record.

7. §2.7 Held evidence is declared evidence: The review_triggers on a policy record name the events that reopen it, and the institution writes that list. The list may not be narrower than what the institution holds. Evidence that bears on whether a policy still serves its stated purpose is held when any part of the institution holds it — an employee, a contractor, a committee it staffs, a specialist it retains to know — and holding it fires the trigger, whether or not that class of evidence was declared. Knowledge that stays in one office while the rule runs from another is still held. A grant that keeps deciding against a rule whose supersession the institution holds has not applied its policy. It is issuing decisions its own records contradict, and §2.3’s clock runs from the day the evidence was held, not the day someone upstairs was told.

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 operator sets both thresholds, the approval rate it treats as near unanimity and the shortest median time in which that information can be read, and publishes them with the specification before the review period begins. The finding is not that the reviewer is at fault. It is that the control has not been shown to be one.

6. §3.6 The routing threshold is part of the specification: Where a score or threshold decides which decisions reach the owner, it is part of the intervention specification, and information_available records what the owner is shown, including any score, and which decisions never reach them. A change to that threshold opens a reconsideration of the specification. A declared share of the decisions that ran without review MUST reach review on a declared cadence, with its approval rate under §3.4 measured apart from the routed queue, because a queue fed only with uncertain cases cannot detect confident errors.

{
  "information_available": [],
  "actions_preventable": [],
  "states_alterable": [],
  "on_disagreement": "dissent logged; the system prevails",
  "incentives": "queue cleared by end of shift",
  "reach_time_target": null
}

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 wears away while nothing about the grant changes, so each component carries a date as well as a description. The dependency record under STD-06 Article V records, for each capacity, when it was last exercised (last_exercised) and whether it is retained, degrading, or lost (status). A capacity that is listed but never exercised is a claim, not 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 at renewal: 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 Capacity is recorded on the grant and rechecked with scope: The seven components of §4.1 MUST be recorded on the grant in correction_capacity, each with its own evidence and an assessed_at date. Capacity MUST be rechecked whenever scope changes, not only at renewal under §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. The grant records, in correction_capacity.detection, who the evaluator is (evaluator) and whether it is independent of the executor (independent_of_executor). This is a correction clause, not a procurement preference. A system that grades its own work 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

Four ways a delegation can satisfy the record format while failing the terms, what meeting the terms looks like, and a caveat for each.

• 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.
  Caveat: 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.
  Caveat: 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.
  Caveat: 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.
  Caveat: A policy may be renewed on unchanged evidence if the renewal is recorded.