Contestatory constitutionalism

A person affected by an automated decision gets a standing channel that brings their objection to a human, who has to respond. The exchange is recorded. Some papers are design frameworks that set out the features such a channel needs, covering both mechanisms built in ahead of time and mechanisms added afterward. Others are working systems, from a ban-appeal channel in a Reddit community of millions to a clinical dashboard where a doctor files structured disagreement with the model's reading. There is also one speculative design concept for a municipal camera car. The fuller designs include notice of the decision and a statement of its grounds, but not all designs do. What all the papers share is that the object of dispute is a single decision, and the remedy is a reply plus a record of what happened.

The people governed by the system write and revise the norms that the system applies to them, rather than disputing an output after it is produced. The system is built to defer to the profile they wrote rather than to a profile fixed inside the model. The interface is the mechanism. It exposes the profile so that it can be inspected, challenged, and revised, which makes the standard itself contestable, and not only its applications. The underlying hypothesis is that pluralism is achieved at the interface level, by giving the standard to the people subject to it, rather than by choosing a better standard centrally.

This approach takes an existing specification and constrains what its words mean. It identifies the interpretive choices the text leaves open, and shows that several equally defensible readings of one principle lead to different model behavior. It then borrows the tools courts and agencies use to limit this divergence. These are a pipeline that rewrites ambiguous rules the way an agency reworks a regulation, and prompt-level canons that constrain how the remaining ambiguity is applied, tested across 5,000 real user scenarios. Within this approach, the papers debate the old jurisprudential question of whether to bind a powerful decider with rules or with accumulated cases. The work concerns how the developer drafts and reads the text. Nothing in it changes who wrote the text or who authorized it.

This approach leaves the wording of the rules unchanged. Instead, it addresses where the authority to make the rules comes from and whether the people subject to that authority can push back. The proposal is a constitution ratified in public rather than written privately inside a lab. Individual applications of the constitution accumulate into a public body of case law that anyone can cite against the next decision. Such an arrangement is assessed with a six-part test from republican political theory (legitimacy, accountability, corrigibility, non-domination, subsidiarity, and institutional resilience). The test is applied first to existing non-majoritarian institutions and then to a hypothetical bounded superintelligent authority. The test is a tool for evaluating this approach, not a separate approach.

This approach gives people who were not involved in building a system a way to report that it failed in real-world use. It also builds the infrastructure that carries the report to whoever can act on it. This includes standard machine-readable formats with rules of engagement, disclosure programs modeled on bug bounties with legal safe harbor for the reporter, and a channel that forwards a single submission to all the developers, coordinators, and registries it concerns. Design frameworks in this approach also cover schemes where the deployer, rather than an outsider, submits the report, and they specify enforcement, anonymity, and what happens after a report. Finally, the approach includes open, searchable archives of real-world failures, and addresses the editorial problem of indexing incidents whose cause, severity, or technical detail is unclear.

This approach keeps a record by default, rather than in response to any particular complaint. The record is meant for whoever later reads it back in bulk. The papers describe two different records. The first is a voluntary, tamper-evident ledger kept inside the developer. It logs models, data, training and evaluation runs, and deployments, along with the approvals, waivers, and attestations that authorized each one. The second is a legally required public register in which platforms file a statement of reasons for every individual adverse action against a user. It received 353 million such statements in a hundred days, comparable across platforms. The two differ in what is recorded and who must record it. What they share is the practice of writing things down by default, so that the exercise of authority can be reconstructed and compared afterward.

The decision is represented formally as a network of claims that support or undercut one another, so a challenger can see which grounds actually carried the outcome. Because the links carry weights, one can compute how sensitive the conclusion is to each link and work out exactly what would have to change for the outcome to differ. Contestation here is built into the system's machinery rather than its interface. It is an exchange the system itself can carry out step by step, revising the decision when a challenge succeeds.