flowchart LR
  A["The refund that everybody<br/>approved and nobody decided"] --> B["On this page"]
  B --> C["Part I. Six rights inside one<br/>decision"]
  C --> D["Part II. Accountability must<br/>follow effective control"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#7B4CD8,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Part I. Six rights inside one decision

Organisations often use one noun for a chain of unlike acts. A model “makes a decision”, a manager “owns the decision”, a committee “signs off the decision”, and a service “implements the decision”. That compression is convenient until an outcome is challenged. Then the review must reconstruct which actor changed information, which actor created authority, which actor changed the world and which actor represented the capability to outsiders.

Decision-rights research has long treated the allocation of rights as an organisational design problem shaped by where relevant knowledge sits and how control is maintained. Jensen and Meckling’s account separates the assignment of decision rights from the control system used to evaluate their exercise. AI introduces a new reason to recover that distinction: the component producing the most fluent account of a choice may hold none of the legal, organisational or technical authority needed to make it effective.

Advice changes the information available to another actor. It can be persuasive, ranked or accompanied by a rationale, but it does not create an authoritative candidate by itself. A risk score, retrieved precedent or model-generated option belongs here when a later actor remains free to construct a different proposal.

Proposal creates the object that may be approved. A defensible proposal is typed and immutable: a named operation, target, amount, conditions, evidence references, policy version and expiry. Free text saying “refund the customer” is not enough if the executor can later choose the amount or recipient. Proposal is where generative interpretation should become a checkable transaction candidate.

Veto is the right to stop, defer or return the path. It differs from approval because a veto may be exercised by policy, security, a customer, a specialist reviewer or the resource service. Several vetoes can coexist. A sanctions rule can block an action that a business approver accepted; the payment service can reject stale state; a customer can withdraw consent.

Approval authorises an exact proposal under stated conditions. It may be a human judgement, a deterministic policy result or a combination, depending on consequence and applicable rules. Approval does not prove execution and should not authorise a mutable intention. Its useful output is a scoped capability or approval receipt bound to the proposal digest and decision state.

Execution attempts the authoritative state change. The executor owns local preconditions, idempotency and effect observation. An approval service may permit a £430 adjustment, but only the account service knows whether the fee still exists, whether it was already reversed and whether the account is blocked. Execution therefore retains a final, narrow veto beside authoritative state.

Public claim is the right to describe what the configured system does. It is often treated as communications rather than authority. That is a mistake. “AI decides”, “human-reviewed”, “fully autonomous” and “95 per cent accurate” shape customer expectation, procurement, oversight and risk acceptance. A claim commits the organisation to a capability interpretation and therefore needs a named approver and evidence boundary.

The strongest baseline: a conventional responsibility chart

A responsibility chart is the strongest practical alternative to this framework. It is familiar, cheap to maintain and often sufficient. A RACI can name who is responsible for a refund process, who is accountable for its design, who must be consulted and who must be informed. When one stable team performs one low-consequence activity through one controlled application, adding six more columns may create taxonomy without better control. The presence of an AI component does not by itself justify a new governance instrument.

The baseline becomes insufficient when a single activity label hides objects that can diverge. “Responsible for refunds” does not reveal whether the reviewer saw the exact proposal later executed, whether the service could change a material parameter, whether security retained a post-approval veto, or whether communications could describe sampled review as universal review. A conventional responsibility cell is normally attached to an activity or process. A decision right is attached to a verb, a typed object, a moment and an enforceable condition.

The discriminating test is reconstruction. Take one consequential case and attempt to recover the candidate, the authority that made it executable, the actor that could stop it, the observed effect and the strongest permitted sentence about the service. If the existing RACI, access controls and logs answer those questions without ambiguity, retain them. If two different paths fit the same row, the chart has compressed a causal distinction. The decision-rights matrix earns its cost only where it separates paths that the baseline cannot distinguish.

The two instruments can coexist. A product owner may remain accountable for the service in the RACI while operations holds case approval, a resource service holds execution, risk owns a veto and communications owns public claims. The matrix does not replace organisational accountability. It makes the operational content of that accountability inspectable.

A minimal worked example: one expense, four different systems

Consider an employee’s £86 train expense. The receipt, policy and output are identical in four configurations. Only the allocation of rights changes.

The visible result, reimbursement of £86, does not reveal which configuration operated. Accuracy alone cannot answer who decided. The answer lives in the enforced path.

Thought experiment: the identical recommendation

Place two systems behind identical screens. Both read the same case, display “approve £430” and produce the same explanation. In System A, the model has no write-capable tool. A caseworker creates the transaction after considering the evidence. In System B, the model has already submitted the transaction; the screen offers a short cancellation window.

Vary no other feature. The model, prompt, output and human interface remain the same. Yet the causal role is different. System A supplies advice. System B executes subject to a possible veto. Calling both “recommendation systems” would hide the only changed feature that matters for authority. Decision rights are properties of the configured system, not of the prose emitted by the model.

Part II. Accountability must follow effective control

Responsibility can be assigned on an organisation chart. Accountability has a stronger burden: a named actor must be able to explain and answer for an outcome within the control, knowledge and resources actually available to them. The OECD accountability principle connects accountability to role, context, ability to act and lifecycle traceability. The NIST AI Risk Management Framework likewise calls for documented roles, communication lines, executive responsibility and differentiated human-AI oversight roles.

Those statements do not imply that one person must approve every case. A product owner can be accountable for the policy, risk acceptance and operating design while caseworkers exercise individual approval rights and services enforce local execution rules. The mistake is to use “owner” as a fog that obscures the actual right exercised at each transition.

Human-factors research supplies a warning older than current AI systems. Bainbridge’s “Ironies of Automation” observed that automation can leave people responsible for rare, difficult interventions while routine practice and situational awareness decline. Parasuraman and Riley’s use, misuse, disuse and abuse framework showed that automation performance depends on the relationship among designers, managers, operators and the technology, not on nominal allocation alone. Elish later named the unfair attribution pattern a moral crumple zone.

The practical implication is severe. Adding a human after the model does not necessarily add independent judgement. It may add only a liability-bearing identity. Ben Green’s review of policies requiring human oversight argues that many such policies assume people can perform oversight functions without establishing the conditions that make oversight effective. This does not prove that human review is useless. It changes the release question from “Is there a human?” to “What can this person know, stop, change and evidence under representative load?”

Thought experiment: the veto button under load

Give two qualified reviewers the same veto button, evidence view and service-level target. Reviewer A receives five cases per day. Reviewer B receives five thousand cases per day, with personal performance measured by throughput. The formal right is identical. Only workload and incentive change.

Reviewer A can inspect contrary evidence, request clarification and stop a transaction. Reviewer B can either sample informally, approve reflexively or create an unmanageable queue. The existence of a button therefore proves interface availability, not effective veto. A right that cannot be exercised within available attention, time and organisational protection is a nominal right.

The EU AI Act makes this operating character visible for high-risk systems. Its human-oversight provisions include the ability to understand capacities and limitations, remain alert to automation bias, interpret output, disregard or reverse it, and intervene or stop the system. The exact legal duties depend on role and use case, but the engineering lesson is broader: oversight has several verbs and must be enabled by design.

A release test for veto should therefore ask six questions. Can the actor see the material evidence and uncertainty? Do they have enough time and skill for the cases routed to them? Can they select more than approve or reject, including referral and correction? Does the interrupt path stop execution mechanically? Are incentives compatible with challenge? Does the record show what was inspected and changed without pretending interaction telemetry proves understanding?

Three accountability layers that should not be collapsed

A compound service needs at least three kinds of answerability. Case accountability belongs to the actor who exercises a right in one case. A caseworker approving the £430 proposal should be able to show the evidence inspected, the policy applied, any correction made and the exact object authorised. Their accountability is bounded by the decision surface and mandate they actually received. It should not silently expand to defects in training data, queue design or permissions they could not alter.

Control accountability belongs to the owners of the configured system. They choose thresholds, review modes, tool access, evidence sources, release criteria, staffing and recovery paths. They may never touch an individual refund, yet they can change the conditions under which thousands of refunds are handled. A control owner should therefore answer for representative-load testing, known limitations, drift, unresolved incidents and the decision to keep the service operating. Naming this layer prevents every failure from being pushed down to the nearest reviewer.

Institutional accountability remains with the organisation and the senior roles through which it accepts risk, meets duties and speaks to customers, regulators or investors. Procurement does not transfer that burden to a model vendor. Nor does assigning a product owner remove the responsibilities of the legal entity or the governance bodies that approved the use. Regimes such as the FCA Senior Managers Regime make explicit responsibilities important in their own context, but this article does not turn one regulatory structure into a universal role map.

The layers overlap without becoming identical. Suppose a reviewer correctly approves a proposal under the policy presented, but a hidden routing defect excluded vulnerability cases from mandatory review. The case decision may be reasonable. The control design may still be defective. If the organisation then claims that every vulnerable case receives specialist review, the institutional claim is also unsupported. One incident can therefore produce different findings against different actors without manufacturing one all-purpose “decision owner”.

A useful review asks each named owner for a verb that matches their layer. Can the case actor correct, refuse or refer? Can the control owner change thresholds, staffing, tools or release status? Can the institutional owner withdraw wording, notify affected parties or accept residual risk? Accountability becomes credible when the assigned answer matches an effective power to prevent, change, repair or represent the outcome.

The decision receipt

A role matrix says who may act. A decision receipt proves what happened. The receipt need not expose private chain-of-thought. It should preserve observable objects that a reviewer can reconstruct: the request, identities, applicable state, admitted context, proposal, policy result, approval, action, effect and recovery status. W3C PROV offers a useful general vocabulary for entities, activities and agents, but a consequential workflow also needs business authority and effect semantics.

The receipt should answer a compact set of questions. What intent initiated the case? Which human, agent and resource identities participated? Which world state and policy version applied? What sources entered context, and which material claims relied on them? What proposal was frozen? Who could veto, who approved and under what scope? What operation was attempted? What effect was observed? Was the system later withdrawn, rolled back or re-released?

Explanation and accountability evidence are complementary, not interchangeable. A generated rationale may help a person understand the proposal. It cannot prove that the approver saw the same amount that the service executed, that a veto was still available or that the expected outcome occurred exactly once.

Part III. Claims are the external edge of decision rights

A system can be internally well controlled and still be described badly. The risk appears when an attractive public phrase compresses several operational facts into one broader interpretation. “Human in the loop” can mean mandatory approval, optional intervention, sampled audit or merely that a person designed the workflow. “AI decision” can mean a score, a proposal, a rule-approved outcome or an executed state change. “Accuracy” can describe a balanced laboratory set while readers infer performance on all live cases.

Claims discipline starts with a simple rule: the strength of the sentence cannot exceed the weakest material link in its evidence chain. Evidence must cover the same version, population, task, decision right and time period as the claim. A metric from a proposal model does not substantiate an execution claim. A ten per cent review sample does not substantiate “every case is reviewed”. A mandatory human approval path does not substantiate “autonomous decisions”, even when the model supplies nearly all analysis.

This principle is not unique to AI. The US Federal Trade Commission’s advertising substantiation policy treats objective claims as requiring a reasonable basis before dissemination. Its final 2025 Workado order followed allegations of unsupported accuracy claims for an AI detector and requires competent, reliable evidence for future efficacy representations. The US Securities and Exchange Commission’s 2024 actions against two investment advisers addressed false or misleading statements about purported AI use. These examples do not supply a universal legal test for every jurisdiction. They demonstrate that AI wording remains answerable to ordinary evidence disciplines.

Separate capability, process and outcome claims

A capability claim says what the configured system can do under stated conditions: retrieve approved sources, prepare a proposal, execute within a limit or stop on a policy result. A process claim says how cases are handled: every case receives human approval, ten per cent are sampled, or a second reviewer handles exceptions. An outcome claim says what happened in a measured population: error rate, correction rate, customer impact or time saved.

These claim types need different evidence. A tool catalogue can support a bounded capability statement, though negative-path tests are still needed. Trace logs and approval receipts support process claims. Adjudicated outcomes with denominators and uncertainty support performance claims. Combining them creates common overreach: “The model achieved 95 per cent agreement, so the system makes safe autonomous decisions with human oversight.” Agreement says nothing by itself about authority, unseen failure cost, actual review or observed effect.

Even the bounded sentence needs version and scope. If version 4 introduces a new execution tool, evidence from version 3 no longer covers the same configured system. If evaluation excludes vulnerable-customer cases, a general customer-outcome claim exceeds the measured population. If approval is mandatory only in one country, an unqualified global statement erases the difference. Claims should therefore carry machine-readable links to their evidence scope even when public prose remains readable.

The authority and communications matrix

The decision-rights matrix becomes useful when joined to communications. For each verb, the organisation records the authorised actor, the receipt that proves exercise and the strongest sentence that evidence permits. The matrix prevents the marketing review from starting with a polished phrase and searching backwards for support.

The claim right should have an expiry or revalidation trigger. Changes to the model, prompt, tool, policy, review mode, population or outcome evidence can invalidate wording without changing the product page automatically. A release pipeline should therefore treat capability claims like other governed assets: versioned, owned, testable and withdrawable.

stateDiagram-v2
  [*] --> Claim
  state "The strongest baseline: a<br/>conventional responsibility<br/>chart" as Claim
  state "A minimal worked example: one<br/>expense, four different<br/>systems" as Test
  state "Thought experiment: the<br/>identical recommendation" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Part IV. Build decision rights into the operating system

The framework becomes concrete in a production-shaped composite. Assume a bank uses an AI-assisted service to investigate disputed account fees and prepare remediation. Every organisation, threshold and volume below is synthetic. The purpose is to expose control logic, not to describe a client deployment.

The service ingests a complaint, account events and applicable policy. A model identifies candidate fee events, explains likely policy treatment and constructs a proposed adjustment. A deterministic policy service verifies product, date, reason code and monetary bounds. Cases with vulnerability indicators, conflicting evidence or adjustments above a local threshold require a caseworker’s approval. A refund service executes only a signed, short-lived capability bound to the proposal digest. The account ledger supplies an effect receipt.

The journey has one accountable product owner, but that owner does not personally approve cases. Operations owns case decisions within delegated limits. Policy owners own rule content. The agent platform owns proposal schemas and trace integrity. The refund service owns final state checks and idempotency. Communications owners approve external wording against the released matrix. Accountability is joined across the path without pretending every participant owns the same decision.

Bind approval to the object that will execute

The most important implementation choice is to stop approving summaries. The caseworker should approve a structured proposal with every material parameter visible. Trusted application code calculates a digest over that proposal, the policy version and the relevant case-state snapshot. The authority service issues a capability for that digest, target operation and time window. The refund service refuses changed parameters, another account, expired authority or a replayed transaction.

If new evidence changes the eligible amount after approval, the digest no longer matches. The path returns for a new proposal or deterministic recalculation under an explicitly approved rule. This avoids the opening incident, where approval of £430 silently became execution of £480. It also distinguishes a recommendation from a standing authority to optimise the outcome.

Put the final veto beside authoritative state

Central policy can decide that a class of adjustment is permitted. It cannot know every live resource condition. The account service must recheck whether the fee remains reversible, whether another remedy already posted and whether legal or operational holds apply. A valid approval is necessary and still insufficient. The executor records one of three states: effect observed, effect rejected or outcome unknown. An accepted request without readback is not proof of success.

Release the claim with the system

The release manifest should include the exact public and internal claims authorised for that version. For the composite, the phrase “AI prepares adjustment proposals; authorised staff approve cases that meet mandatory-review rules” is tied to tests showing proposal generation, routing and approval. A separate phrase about automated low-value execution requires evidence for policy enforcement, local checks, effect monitoring and review sampling. If the review mode changes, the claims gate fails until wording and evidence are reconciled.

Executable artefact: decision-rights and claim audit

The companion Python artefact turns the matrix into release assertions. It uses only the standard library and synthetic fixtures. The positive case separates proposal, approval and execution, tests veto capacity and uses bounded claim wording. The negative case lets one agent propose and execute, supplies no approver, overloads the nominal veto and claims universal human review from a ten per cent sample.

"""Decision-rights and capability-claim audit.

Synthetic teaching artefact for the article
"Decision Rights, Accountability and Claims Discipline".

Python 3.11+. Standard library only.

The validator checks whether a consequential AI-assisted workflow keeps six
rights distinct: advise, propose, veto, approve, execute and make a public
capability claim. It also checks whether claim wording is supported by the
same workflow version, population and review denominator.

This is an architecture test, not a legal or regulatory compliance engine.
"""

from __future__ import annotations

from dataclasses import dataclass
from typing import Any, Iterable

RIGHTS = ("advise", "propose", "veto", "approve", "execute", "claim")
AI_ACTORS = {"complaint_agent", "decision_agent", "language_model"}


@dataclass(frozen=True)
class AuditResult:
    case: str
    errors: tuple[str, ...]

    @property
    def passed(self) -> bool:
        return not self.errors

    def render(self) -> str:
        status = "PASS" if self.passed else f"FAIL ({len(self.errors)} findings)"
        lines = [f"{self.case}: {status}"]
        lines.extend(f"  - {error}" for error in self.errors)
        return "\n".join(lines)


def _roles(case: dict[str, Any], right: str) -> set[str]:
    return set(case.get("rights", {}).get(right, []))


def _contains_ai(actors: Iterable[str]) -> bool:
    return any(actor in AI_ACTORS for actor in actors)


def audit(case: dict[str, Any]) -> AuditResult:
    errors: list[str] = []
    name = str(case.get("name", "unnamed_case"))
    material = bool(case.get("material", False))
    rights = case.get("rights", {})
    controls = case.get("controls", {})
    review = case.get("human_review", {})
    claim = case.get("public_claim", {})

    missing_rights = [right for right in RIGHTS if right not in rights]
    if missing_rights:
        errors.append("rights matrix omits: " + ", ".join(missing_rights))

    owner = case.get("accountable_owner")
    if not isinstance(owner, str) or not owner.strip():
        errors.append("no named accountable owner for the configured workflow")

    approvers = _roles(case, "approve")
    proposers = _roles(case, "propose")
    executors = _roles(case, "execute")
    vetoers = _roles(case, "veto")
    claimants = _roles(case, "claim")

    if material and not approvers:
        errors.append("material state transition has no approval right")
    if material and approvers and _contains_ai(approvers):
        errors.append("AI actor holds the approval right for a material transition")
    if material and not vetoers:
        errors.append("material transition has no declared veto or stop right")
    if material and not executors:
        errors.append("material transition has no declared executor")
    if not claimants:
        errors.append("no role is authorised to approve public capability claims")

    if material and proposers & executors and not controls.get(
        "proposer_executor_separation_justified", False
    ):
        errors.append(
            "the same actor proposes and executes a material change without an explicit separation justification"
        )

    if material and not controls.get("proposal_immutable", False):
        errors.append("approved proposal is not immutable")
    if material and approvers and not controls.get("approval_binds_proposal", False):
        errors.append("approval is not cryptographically or transactionally bound to the executed proposal")
    if material and not controls.get("executor_enforces_capability", False):
        errors.append("executor does not enforce a scoped authority object")
    if material and not controls.get("effect_receipt", False):
        errors.append("workflow does not record an observed effect receipt")

    expected = controls.get("expected_cases_per_day")
    capacity = controls.get("veto_capacity_per_day")
    if vetoers and isinstance(expected, (int, float)) and isinstance(capacity, (int, float)):
        if capacity < expected:
            errors.append(
                f"veto right is operationally under-capacity: {capacity:g} reviews for {expected:g} expected cases per day"
            )
    elif vetoers and material:
        errors.append("veto right has no declared workload and capacity test")

    assertions = set(claim.get("asserts", []))
    review_fraction = float(review.get("fraction", 0.0))
    review_mandatory = bool(review.get("mandatory", False))

    if "ai_proposes" in assertions and not _contains_ai(proposers):
        errors.append("claim says AI proposes, but no AI actor has the proposal right")
    if "ai_decides" in assertions and not _contains_ai(approvers):
        errors.append("claim says AI decides, but the approval right belongs elsewhere")
    if "human_approves" in assertions:
        if not approvers or _contains_ai(approvers) or not review_mandatory:
            errors.append("claim says a human approves, but mandatory human approval is not enforced")
    if "human_reviews_all" in assertions and review_fraction < 1.0:
        errors.append(
            f"claim says every case is human-reviewed, but the declared review fraction is {review_fraction:.0%}"
        )
    if "autonomous_decisions" in assertions and review_mandatory and approvers:
        errors.append("claim says decisions are autonomous while mandatory human approval remains in the workflow")
    if "autonomous_execution" in assertions and not controls.get("executor_enforces_capability", False):
        errors.append("autonomous-execution claim lacks enforced scope at the execution boundary")

    for field, message in (
        ("version_match", "claim evidence belongs to a different system version"),
        ("population_match", "claim evidence does not cover the claimed population"),
        ("scope_match", "claim evidence does not cover the claimed workflow scope"),
    ):
        if claim and not claim.get(field, False):
            errors.append(message)

    if "human_reviews_all" not in assertions and review_fraction < 1.0:
        if claim.get("uses_unqualified_human_review_wording", False):
            errors.append("unqualified 'human-reviewed' wording hides that review is sampled")
        if not claim.get("denominator_disclosed", False):
            errors.append("sampled human review is claimed without its denominator")

    return AuditResult(name, tuple(errors))


POSITIVE_CASE: dict[str, Any] = {
    "name": "bounded_fee_adjustment_v3",
    "material": True,
    "accountable_owner": "customer_remediation_product_owner",
    "rights": {
        "advise": ["complaint_agent"],
        "propose": ["complaint_agent"],
        "veto": ["caseworker", "policy_service"],
        "approve": ["caseworker"],
        "execute": ["refund_service"],
        "claim": ["product_owner", "communications_reviewer"],
    },
    "controls": {
        "proposal_immutable": True,
        "approval_binds_proposal": True,
        "executor_enforces_capability": True,
        "effect_receipt": True,
        "expected_cases_per_day": 120,
        "veto_capacity_per_day": 160,
        "proposer_executor_separation_justified": False,
    },
    "human_review": {"mandatory": True, "fraction": 1.0},
    "public_claim": {
        "text": "AI prepares fee-adjustment proposals; authorised staff approve each adjustment before execution.",
        "asserts": ["ai_proposes", "human_approves"],
        "version_match": True,
        "population_match": True,
        "scope_match": True,
        "denominator_disclosed": True,
        "uses_unqualified_human_review_wording": False,
    },
}


NEGATIVE_CASE: dict[str, Any] = {
    "name": "overclaimed_autonomy_v1",
    "material": True,
    "accountable_owner": "",
    "rights": {
        "advise": ["decision_agent"],
        "propose": ["decision_agent"],
        "veto": ["operations_reviewer"],
        "approve": [],
        "execute": ["decision_agent"],
        "claim": [],
    },
    "controls": {
        "proposal_immutable": False,
        "approval_binds_proposal": False,
        "executor_enforces_capability": False,
        "effect_receipt": False,
        "expected_cases_per_day": 900,
        "veto_capacity_per_day": 80,
        "proposer_executor_separation_justified": False,
    },
    "human_review": {"mandatory": False, "fraction": 0.10},
    "public_claim": {
        "text": "Fully autonomous, human-reviewed AI decisions.",
        "asserts": ["autonomous_decisions", "human_reviews_all", "human_approves"],
        "version_match": False,
        "population_match": False,
        "scope_match": True,
        "denominator_disclosed": False,
        "uses_unqualified_human_review_wording": True,
    },
}


def main() -> None:
    positive = audit(POSITIVE_CASE)
    negative = audit(NEGATIVE_CASE)
    print(positive.render())
    print()
    print(negative.render())

    # Positive and negative cases make the teaching contract executable.
    assert positive.passed, positive.errors
    assert not negative.passed
    assert any("human-reviewed" in error or "every case" in error for error in negative.errors)
    assert any("under-capacity" in error for error in negative.errors)


if __name__ == "__main__":
    main()

Failure-injection tests before release

A happy path can preserve the vocabulary while the controls remain decorative. The release suite should deliberately break the relationships the matrix claims to enforce.

When several rights may safely collapse

Separation is a control choice, not a moral preference for more handoffs. Several rights may sit with one actor when the authority envelope is small enough that independent approval would not materially improve the outcome. Five properties matter: consequence, reversibility, observability, contestability and externality. A low-consequence change that is immediately visible, easily undone, privately contained and open to correction creates little pressure to separate proposal from execution. A high-consequence or irreversible change creates much more.

Consider the private spelling assistant used as the negative control. It may read a sentence, propose “accommodation”, replace the misspelling and let the writer undo the change. Advice, proposal and execution collapse into one interaction. The user retains a practical veto through preview or undo, the affected object is the user’s own draft, and the effect is directly observable. Requiring a second approver would add delay while leaving the principal risk, an unnoticed bad edit, almost unchanged.

Now vary one feature at a time. If the assistant sends the corrected text to a customer, externality rises and send authority should separate from editing. If it changes a filed regulatory return, reversibility falls and approval should bind to the exact document. If edits happen invisibly across thousands of records, observability falls and sampling, reconciliation or a hard limit becomes necessary. If the affected person cannot challenge the result, contestability falls and a route for review becomes part of the authority design.

A useful collapse rule is therefore conditional: combine rights only while the worst credible effect remains bounded, detectable and recoverable inside the actor’s legitimate scope. Record the condition and an expiry trigger. A new tool, broader population, higher limit, silent execution path or stronger public claim should reopen the allocation. Rights may collapse inside a narrow envelope; the evidence for that envelope may not.

Where the framework stops helping

The six-rights matrix does not determine whether the underlying policy is just, lawful or effective. It can clearly show that a human approved a proposal built from biased evidence. It can prove that a resource executed exactly what was authorised even when the authorised outcome harms a customer. It can allocate rights among actors who collude or share the same blind spot. Those are substantive governance, evidence and institutional-design problems.

The negative control prevents the framework from becoming a segregation ritual. Its purpose is not to maximise the number of approvers, services or receipts. It is to preserve distinctions whose collapse would change consequence, recourse or the truth of a claim. Where the five envelope tests remain favourable, one actor may hold several rights. Where one test deteriorates, the allocation should split at the point that restores effective control. Proportionality therefore belongs inside the design, not as an exemption applied after the matrix is complete.

Finally, explicit roles can ossify. A matrix copied from policy may remain unchanged while tools, thresholds and human practice drift. The control therefore requires reconciliation against deployed permissions, traces, queue capacity and public wording. The artefact is alive only when a changed system can make it fail.