{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"authority_legitimacy_and_consent_foundations__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"authority_legitimacy_and_consent_foundations__computer_science__P1","proposal_index":1,"version":0,"title":"Delegated Rollback Charters for Autonomous Production Controllers","problem":"An autonomous rollback controller has technical credentials to reverse deployments across multiple production services, but service teams lack a stable basis for treating its decisions as authorized. Its mandate, qualifying evidence, jurisdiction, and challenge path are unclear, so teams disable or bypass it after disputed actions even when organization-wide policy nominally empowers it.","actors":["Service owners whose deployments may be reversed","On-call engineers responsible for incident response","Platform engineers operating the rollback controller","Production-governance or reliability leaders delegating authority","Downstream service teams and users exposed to rollback consequences","Reviewers adjudicating disputed or out-of-scope actions"],"observable_state":"Repository and incident records show inconsistent controller enablement, local bypasses, emergency credential revocations, repeated disputes about whether a rollback was permitted, and rollback records that identify a trigger but not the mandate, scope rule, competence qualification, or appeal route supporting the action.","consequence":"Incident response fragments across teams: engineers spend active incidents contesting jurisdiction, authorized automation is inconsistently used, and an erroneous or out-of-scope rollback can alter production without an accountable basis.","affected_objective":"Safe, timely, and accountable containment of deployment-caused failures without granting an automated controller open-ended production authority.","intervention":"Create a machine-readable Delegated Rollback Charter for each participating service. Jointly approved by the service owner and production-governance delegate, it specifies the controller's authority source, eligible decision class, telemetry predicates, maximum rollback scope, validity period, downstream-party representation, competence qualification, conflicts, suspension conditions, and review route. Before acting, the controller must validate the proposed rollback against the charter; afterward it must emit a signed public-reason packet and expose an immediate suspension-and-appeal control. Authority expires unless renewed and cannot expand from observed operator behavior or silence.","structural_mapping":[{"archetype_element":"Structural problem","domain_realization":"The controller possesses production credentials but lacks an intelligible and accepted right to bind service teams by reversing their deployments."},{"archetype_element":"Authority Mandate","domain_realization":"A jointly approved Delegated Rollback Charter states why the controller may act and which production decisions it may make."},{"archetype_element":"Authority Boundary","domain_realization":"The charter limits authority by service, deployment type, telemetry predicate, rollback depth, time window, dependency blast radius, and expiration or revocation trigger."},{"archetype_element":"Affected Party Recognition","domain_realization":"The charter identifies service owners, on-call responders, dependent-service representatives, and production governance as parties who authorize, bear consequences, receive notice, or review decisions."},{"archetype_element":"Consent Scope","domain_realization":"A service owner authorizes a specific controller version and action class for a fixed period; silence and general platform enrollment do not count as consent, and suspension is immediately available."},{"archetype_element":"Competence Evidence","domain_realization":"A controller version qualifies only after peer-reviewed replay against service-specific historical incidents, including checks for prohibited rollback recommendations."},{"archetype_element":"Public Reason Record","domain_realization":"Every proposed or executed rollback produces a signed packet containing the triggering evidence, applicable charter clauses, alternatives considered, confidence limits, and review instructions."},{"archetype_element":"Accountability and Review Path","domain_realization":"An independent reviewer can determine whether the controller exceeded its mandate, invalidate the action class, require charter repair, or refer technical defects to the platform team."},{"archetype_element":"Legitimacy Health Indicator","domain_realization":"The program tracks expired charters, suspensions, jurisdictional appeals, out-of-scope recommendations, unresolved reviews, and representation gaps without treating low complaint volume as consent."}],"mechanism_mapping":[{"mechanism_slug":"charter_or_mandate_document","role":"The machine-readable charter binds controller permissions to an explicit delegation, scope, duration, and revocation rule.","counterfactual_removal":"Without the charter, production credentials or a platform policy would remain the de facto mandate, leaving service-specific jurisdiction ambiguous."},{"mechanism_slug":"consent_capture_and_revocation_workflow","role":"Records scoped approval from service owners and governance delegates and propagates suspension or expiration to the controller's authorization check.","counterfactual_removal":"Without this workflow, enrollment, silence, or outdated approval could be misrepresented as continuing authorization."},{"mechanism_slug":"credentialing_and_peer_review_process","role":"Qualifies each controller version for the bounded decision domain using replay evidence and review by reliability and service-domain peers.","counterfactual_removal":"Without qualification, formal delegation could legitimate a controller whose demonstrated competence does not match the decisions entrusted to it."},{"mechanism_slug":"public_reason_giving_protocol","role":"Requires each rollback decision to expose its evidence, governing charter clauses, limits, and challenge route in a durable record.","counterfactual_removal":"Without reason-giving, affected engineers could observe the production change but could not distinguish an authorized decision from a defect or boundary violation."},{"mechanism_slug":"appeal_or_review_forum","role":"Provides a forum empowered to suspend authority, adjudicate boundary disputes, and require repair after error or overreach.","counterfactual_removal":"Without an outcome-changing review path, objections would revert to credential revocation, informal bargaining, or postmortems unable to correct the authority foundation."}],"causal_chain":["A controller's credentials allow it to reverse deployments, but credentials alone do not establish accepted decision authority.","The charter names the binding decision, authority source, affected parties, and jurisdictional boundary.","Scoped approval and expiration connect the authority to current delegation rather than inferred acquiescence.","Replay qualification connects competence evidence to the particular rollback domain.","Runtime charter validation prevents the controller from exercising delegated authority outside its encoded boundary.","A signed reason packet makes each authority claim and its evidence inspectable.","Suspension and review let affected parties contest error, conflict, or mandate drift and change future authority.","If these links hold, disagreement can be resolved as a mandate, competence, evidence, or boundary question instead of through blanket acceptance or disabling of the controller."],"baseline":"The baseline is a rollback controller authorized through broad platform credentials, organization-wide policy, and locally configured thresholds. Teams may disable it or seek human approval ad hoc, while incident postmortems provide retrospective explanation but no service-specific delegation, expiration, or empowered jurisdictional appeal.","nearest_rivals":["Role-based access control or capability scoping can restrict which production operations the controller can invoke, but does not establish affected-party authorization, competence evidence, reason-giving, or review.","Mandatory human approval for every rollback supplies case-specific authorization, but does not create bounded, durable delegation for time-sensitive automated action.","Improved anomaly thresholds, testing, and rollback accuracy address technical competence but do not determine who may bind a service team or how that authority can be challenged.","A conventional incident runbook assigns operational steps but may omit consent scope, mandate expiration, downstream representation, and an outcome-changing appeal path."],"remaining_contrastive_claim":"Conditional on disputed authority being a material cause of bypass, the chartered design differs from access control and accuracy tuning by making automated rollback authority simultaneously delegated, service-bounded, competence-qualified, reason-giving, and revocable. The claim fails if technical reliability or latency alone explains operator behavior.","authority_safety":{"decision_authority":"Service owners and the designated production-governance delegate jointly approve, renew, narrow, or revoke a service charter. The controller may decide only charter-conforming rollbacks; an incident commander retains authority for unchartered cases, and the review forum may suspend but not silently broaden the controller's mandate.","authorized_first_step":"The first step is limited to retrospective and shadow-mode evaluation on records voluntarily supplied by three service teams; it may generate recommendations and reason packets but cannot invoke production APIs.","excluded_actions":["Executing or scheduling a production rollback","Adding, rotating, or widening production credentials","Treating repository membership, employment, silence, or prior platform use as consent","Enrolling services or downstream representatives without explicit authorization","Changing incident-response policy outside the participating services","Using telemetry or incident content beyond the approved evaluation dataset","Allowing the controller or its platform maintainers to adjudicate their own contested action"],"halt_rollback":"Stop the evaluation if it exposes restricted incident data, generates an out-of-scope recommendation, lacks an identifiable affected-party representative, or produces a charter interpretation that reviewers cannot reproduce. Disable the shadow evaluator, preserve an access-controlled audit record, invalidate the affected draft charter, and resume only after joint reauthorization."},"negative_tests":{"strongest_counterevidence":"A blinded incident audit finds that teams already recognize the controller's mandate, scope, and review path, while every bypass is explained by false recommendations, excessive latency, or missing integrations rather than contested standing.","problem_falsifier":"Interviews and records show no jurisdictional disputes, inferred consent, mandate drift, or inability to challenge decisions; operators can consistently state who authorized the controller, where its authority stops, and how review can change outcomes.","intervention_falsifier":"In shadow evaluation, charter and reason records do not improve agreement about whether actions are authorized, reviewers cannot apply the boundaries consistently, or teams still require case-by-case human approval even for technically correct charter-conforming recommendations.","risks":["A polished charter could become legitimacy theater while production credentials remain broader than the documented mandate.","Service-owner approval could be coerced by organizational hierarchy or fail to represent downstream teams and users.","Historical replay could overstate competence because future incidents differ from the qualification set.","Detailed reason packets could disclose sensitive topology, vulnerabilities, or incident data.","Review procedures could add delay during urgent incidents or be captured by the platform organization.","Frequent expirations could create operational gaps, while automatic renewal could turn scoped consent into fictional consent.","Encoding ambiguous policy into machine-readable rules could conceal value judgments behind apparent technical precision."]},"next_evidence_step":"Run a four-week, non-production shadow study with three explicitly consenting service teams and a preselected set of 24 historical deployment incidents. Draft one charter per service, have the controller produce recommendations and reason packets, and ask service owners, on-call engineers, and an independent reviewer to classify authorization, scope compliance, and appeal disposition before and after seeing the charter. Record disagreements, out-of-scope recommendations, review reproducibility, representation gaps, and time required; do not connect the evaluator to production credentials.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation prohibits inspecting other proposals; this candidate is derived solely from the supplied archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot construction of a concrete computer-science authority problem","Complete causal and operational mapping to the supplied archetype","Bounded, non-production evidence step with explicit safety authority"],"conceptual_changes":["None; this is version 0."],"operational_changes":["None; this is version 0."],"evidence_changes":["No external evidence or prior-art search was used."],"claim_changes":["The candidate makes only a conditional contrastive claim and no claim of novelty, prevalence, demand, or effect size."]}}