Status: DRAFT
Governance from the AI user's workflow¶
Runtime reference model. Where the control-and-evidence layer asks what an operator must prove, this asks what a person using AI must decide, trace, and escalate.
Core rule¶
Trace wide, escalate narrow. Keep a reviewable record of the workflow, but interrupt the user only when a human decision can materially change the outcome. Escalating everything trains people to click "allow all"; good tracing is what earns the right to escalate less.
Escalate only when all three hold: a human can change the outcome, the stakes justify interruption, and the AI cannot responsibly resolve it alone. Otherwise, trace and proceed only within valid authority and satisfied requirements; if a required check fails, remain blocked even when human escalation would not help.
Five steps¶
The user-facing workflow uses ordinary verbs: plan the use → prepare the inputs → check the evidence → decide the action → review the effects. Each step has a corresponding operational gate:
| Step and gate | User question | Governs |
|---|---|---|
| 1. Plan → Authorize | Is AI — and this system — right for the purpose, and what is at stake? | purpose, provider/system suitability, authority, limits, risk tier |
| 2. Prepare → Submit | May these data, sources, and instructions enter the system safely? | input provenance, privacy, IP/confidentiality, trust boundary |
| 3. Check → Verify | What is it claiming, is the evidence sound enough for this use, and was its source in a position to establish it? | evidence, source validity and standing, uncertainty |
| 4. Decide → Commit | Should this exact output affect a decision or external action? | consequence, fairness, notice, human sign-off where needed |
| 5. Review → Rely | What happened, can it be challenged or corrected, and should reliance continue? | effects, complaint, remedy, correction, reliance |
Conditions across every step¶
- Allowed, able, accountable: the user is authorized to use the tool, competent to oversee it, and responsible for what they ship.
- Safety, privacy, resilience: misuse resistance, data protection, and fallback/exit where reliance is material.
- Fairness: for consequential uses, ask whether the output may be systematically worse for some affected group.
- Traceability: record what was asked, used, claimed, decided, challenged, and fixed.
Gates and fail actions¶
| Gate | Pass condition | If it fails |
|---|---|---|
| Authorize | purpose and limits defined; system sanctioned; user permitted and competent | set scope, use an approved system, get trained, or get sign-off |
| Submit | data, sources, and instructions permitted; privacy/IP/confidentiality basis is clear | redact, isolate, replace the input, or do not submit |
| Verify | sources resolve; where a claim class has an entitled source, the citation's standing is recorded; evidence checked, uncertainty carried forward | keep verifying; do not convert doubt into certainty, or an unattributed source into an established fact |
| Commit | evidence and fairness considered; accountable human signs off where needed | hold, seek independent review, or reject |
| Rely | challenge/remedy route works and remains current | switch, add fallback, or withdraw reliance |
Loops and chains re-enter Submit and Verify: each model/tool hop can add fresh data, untrusted instructions, unverified claims, or drift. For autonomous or high-frequency actions, Authorize establishes a bounded operating envelope with limits, monitoring, rollback, and a safe stop; Commit remains point-of-effect verification by the service executing the action.
Two different permissions, easily conflated. Submit asks whether an input may enter — privacy, IP, confidentiality, trust boundary. Verify asks something else: whether whoever supplied it was entitled to establish the fact it is now being used for. A document can be entirely admissible to read and still not be the thing that settles the question, so admission to the workflow is not standing and must not be recorded as though it were. The same rule applies to people and is the sharper case: a person has standing over their own testimony, interpretation, and permission, and a third party's facts are resolved by cited evidence or routed to that party — never by bare assertion, because no sign-off can supply a missing evidentiary basis. Where standing cannot be established, carry the input forward as unattributed rather than as evidence — and where no source is entitled to establish the claim at all, record that instead of holding it against the input, because absence of an entitled source is a fact about the claim, not a defect in the citation.
Authority needs the same treatment as evidence. Authorize establishes what the user and system may do, but the authority at the root of that grant has a basis too — a role, an instrument, a decision — and it should be recorded and reviewable rather than assumed from the fact that a grant exists. A signed permission proves someone granted it, never that they held what they granted.
EGA presents these as instances of one repeated check: may this proposed transition proceed under its applicable requirements? Any check may obtain permitted evidence, including evidence establishing authority or permission. Trusted rules select the requirements; the acting AI cannot select a bypass. The overview illustrates these checks in a simplified control flow, without replacing the operational gates, technical verdicts, attempt states or recovery obligations below. After the checked step, record the outcome. Then end the workflow or optionally prepare further work within current permission and applicable checks. A refusal may end with the step withheld and the reason recorded; it need not lead to revision or human judgment. Where permitted, Working AI receives permitted feedback and revises within its current permission; the changed proposal follows the correction route through applicable checks in a new attempt. The rejected step remains blocked; uncertainty still requires reconciliation. “Human judgement where needed” is a conditional route for a specific unresolved issue, within the person's authority; it is not required for every refusal and cannot substitute for missing evidence or authority, or reopen a terminally closed attempt.
Escalation triggers¶
Every trigger is traced. It interrupts only when material in context: Silent (log), Flag (surface non-blocking), or Stop (block for decision).
Two layers, two vocabularies. Silent, Flag, and Stop describe what the person experiences. Where an independent authorization component gates a consequential action, it returns allow, deny, or escalate against the current mandate and policy (see the Charter Commitments). They are not synonyms: only escalate necessarily produces a Stop, a deny is a machine refusal that may never reach a person, and an allow can still carry a Flag.
Calibration runs on two axes. The use case and stakes set where Stop kicks in: irreversible, external, regulated, or person-affecting → Stop readily; internal, reversible, or draft → mostly Silent trace. The user — competence, role, standing preferences — sets the manner and frequency: an expert with standing preferences → fewer, decision-only asks; a novice in a high-stakes domain → escalate more, and explain.
What the AI knows - Low confidence or genuine uncertainty — Flag → Stop if consequential. - Conflicting evidence — Flag → Stop; surface the disagreement. - Missing load-bearing input or assumed intent — trace; Flag if important. - Beyond declared scope or would need fabrication — Stop.
What is at stake - Risk to people, rights, safety, or security — Stop. - Material opportunity or clearly better option — Flag. - Irreversible action — send, publish, delete, pay, deploy, sign — Stop. - Threshold crossing — spend, scope, people affected, quota — Stop at threshold. - Consequential decision about an identifiable person — Stop.
Authority and boundaries - Scope creep, legal/policy/rights boundary, new privilege/tool/data, external action on the user's behalf, or money/resource commitment above threshold — Stop.
Data, privacy, and rights - Sensitive/personal/third-party data leaving a boundary — Stop. - Input/output IP or confidentiality uncertainty — Flag → Stop. - External disclosure across a trust boundary — Stop.
Conflict and integrity - Value tradeoff, stakeholder conflict, prompt injection, manipulation, or harmful false premise — Flag → Stop.
Lifecycle - Material dependency/source/version change — Flag → Stop. - Repeated failure — Flag. - Earlier error discovered — Flag → Stop; correct and surface.
Human intervention contract¶
A Stop is not an alert to whichever person happens to be available. Every material Stop — including one produced by a machine escalate response — needs a declared intervention contract:
| Contract field | Must answer |
|---|---|
| Trigger and state | Which event and rule caused the intervention; at which gate; and what are the current action, system, mandate, and policy states where applicable? |
| Decision and route | What exact decision is required; which authorized role may make it; what competence and independence are required; and who may substitute — or which safe state persists if no substitute is permitted? |
| Decision basis | Which material evidence, uncertainty, consequences, reversibility, alternatives, and conflicts must that person see? |
| Response bound and default | By when must the decision arrive; what safe state applies while waiting; and what happens on timeout or no response? If the decision would grant or extend authority, no response fails closed; only a declared reversible fallback already within existing authority may proceed. |
| Permitted dispositions | May the decision-maker allow within scope, deny, narrow or modify, seek outside review, cancel or reverse, or route to remedy? |
| Record and feedback | Which authorization, review, override, or remedy decision, reasons, timing, action, and effect are recorded; what can be challenged; which monitoring signal is updated; and can the result constrain, re-authorize, suspend, or withdraw the operating envelope or system? |
Route by authority, not proximity: authorization goes to the principal or a valid delegate; consequential domain judgment to a competent accountable official; conflicted or contested cases to independent review; challenge and remedy to an empowered remedy decider; and aggregate or lifecycle signals to the accountable release owner or regulator. The five-role institutional model explains why rulemaking, operation, record custody, independent review, and remedy should not collapse into one unchecked actor.
Preventing "allow all"¶
- Escalate decisions, not mechanics. Ask one framed question with options, tradeoff, recommendation, and default.
- Scope every grant. Permission is for this action and resource, not everything forever.
- Use safe defaults on silence. Timeout cannot grant or extend authority. It selects only a declared reversible fallback already within existing authority; otherwise the Stop remains.
- Watch escalation rate. If the system asks too often, re-scope the task or tool.
What this is¶
A design synthesis, not a certifiable checklist. It maps provider-side Charter duties — notice, review, remedy, evidence, correction — onto the user's seat. Collective or diffuse harms need representative, regulator, or system-level review outside this single-user loop.