A law can be debated in public, amended by a legislature, interpreted by a court, and repealed when experience proves it defective. Software can also implement a law, but it does more than record the decision. It determines what a person can see, which actions are possible, what evidence counts, and how quickly an institution can respond. When essential public life is mediated by software, implementation choices become a form of legislation by infrastructure.
This does not mean that code is secretly the only law, or that every application is a constitution. It means that a rule written in a statute may be changed in practice by a database schema, an interface, a default setting, an identity requirement, or an automated rejection. The public may retain a formal right while lacking a usable path to exercise it. The central question is therefore democratic: who decides the conditions of participation when those conditions are built into systems few citizens can inspect?
The answer cannot be to reject software. Public institutions need reliable systems for records, payments, communication, transport, health, and elections. The task is to govern infrastructure as a revisable political choice. Systems must be versioned, contestable, auditable, replaceable, and accountable to the people they organize. A society becomes software in the dangerous sense when its arrangements become so technically fixed that democratic judgment cannot alter them.
Implementation Is Interpretation
Every implementation chooses among possibilities that a statute may leave open. An agency deciding how an application form handles a missing field is deciding whether the person receives help or an automatic barrier. A transportation system deciding whether payment must be digital is deciding who can travel. A school portal deciding which guardian can edit a record is deciding how family authority is recognized. These are not merely engineering details when they distribute access, burdens, or opportunities.
The discretion is often hidden in defaults and dependencies. A procurement contract may require a proprietary identity service. A vendor may define a “duplicate” claim in a way that excludes a household with shared documents. An interface may make appeal technically available but practically unreachable. A data standard may omit a disability, language, or family structure. The system then acts like a silent regulator: not by announcing a new policy, but by making some conduct easy and other conduct costly or impossible.
Catholic social teaching gives an institutional test for these decisions. The common good concerns the conditions that allow persons and groups to flourish (Gaudium et Spes 26), and solidarity demands attention to people made vulnerable by social arrangements. Subsidiarity, especially in Quadragesimo Anno 79–80, asks that higher authorities support rather than absorb the capacity of smaller communities. Infrastructure that centralizes every decision, data source, and remedy can weaken both participation and subsidiarity, even if it is efficient on its own technical terms.
The Brittleness of Total Systems
Software is praised for consistency, but a single assumption can become a single point of failure. A database migration can corrupt records. An identity provider can go offline. A security update can break a critical workflow. A change in a vendor's terms can make a public service dependent on a private business decision. When many institutions share a cloud, standard, or authentication layer, an error travels farther and faster than an individual clerical mistake.
Institutional brittleness is not only an availability problem. A system can be online and still fail constitutionally or morally. It can reject people whose documents do not match, make a lawful exception impossible, expose sensitive information, or produce a record that no office knows how to correct. It can preserve a bad policy perfectly, tempting an institution to call the output authoritative because changing it is difficult.
Resilience therefore requires more than backups. It requires a human fallback, alternative access channels, independent records where appropriate, tested restoration, clear ownership, and the ability to suspend a harmful process. A service that cannot operate during a vendor outage or correct a mistaken record has made technical dependency part of its law without debating that choice.
A Rubric for Purposeful Integration
The choice between integration and fragmentation should be made as an architecture decision, not as a slogan. For each service, record its criticality, the correlation of likely failures, recovery-time and recovery-point needs, accessibility, privacy exposure, switching cost, and total lifecycle cost. A shared identity or data layer is more defensible when it materially improves the service and has independent recovery paths; it is less defensible when one error can deny several rights at once and no alternative channel exists. The same rubric should name who bears the cost of delay, duplication, or a breach.
Staged deployment, a tested manual fallback, and migration support should be required in proportion to the service's impact, not imposed as ceremonial duplication on every small agency. A low-stakes internal tool may need only versioned records and a restoration test; an essential benefits or health system may need a staffed alternative, independent records, and rehearsed recovery. NIST and OECD governance guidance can organize the assessment, but they do not supply a universal threshold for centralization. That threshold remains an evidence-based public choice, revisited when outage, accessibility, privacy, or switching-cost data change.
Versioning and the Possibility of Change
Law lives through revision. A legislature can discover that a threshold is too harsh, a court can reject an interpretation, and an agency can learn from appeals. Public software should preserve that possibility. Every consequential system needs version control for code, policies, data definitions, model configurations, and permissions. The institution should know what rule was in force when a decision was made and who authorized the change.
Versioning is not a technical luxury. It supports notice, equal treatment, audit, and remedy. If an applicant is denied under a rule changed six months later, the agency needs to reconstruct the earlier logic. If a model is updated, the public should know what changed, what testing occurred, and whether old decisions will be reviewed. Records should be protected against tampering while respecting minimization and retention limits; an immutable log of everything is not automatically good governance.
A harmful release should be suspendable without waiting for a complete replacement, but suspension does not always mean technical rollback. Schema changes may have rewritten records; security incidents may make restored credentials unsafe; distributed systems may have committed different states across replicas; and an automated decision may have triggered an irreversible payment, disclosure, or physical action. In those cases, restoring an earlier software version can create new corruption or conceal what happened. The responsible response may be containment, a forward fix, migration to a corrected schema, reconstruction from trusted records, notification, or compensation.
Continuity plans should therefore define the authority to pause a process, preserve evidence, communicate with affected people, and choose among rollback, forward remediation, migration, reconstruction, or restitution. They need tested backups and manual procedures, but also a way to correct decisions already made and to review whether people suffered loss. Revisability is an institutional requirement: public authority must be able to change a policy, stop a harmful implementation, and provide a remedy. It is not a promise that every technical state can be reversed or that history can be restored by pressing a button.
Public Contestability
Contestability means more than publishing source code. A citizen may not be able to read a repository, and a public inspection of code may reveal little about data quality, institutional incentives, or the actual effect of an interface. A contestable system offers intelligible notice, reasons for consequential outcomes, a route to human review, accessible records, and an authority able to change the result. It makes the policy embodied in the system available for disagreement.
Public participation should occur before deployment as well as after harm. Agencies can publish impact assessments, proposed data fields, procurement specifications, security assumptions, retention periods, and fallback plans. They can consult affected residents, frontline workers, disability advocates, civil-society groups, and local communities. Consultation cannot replace a lawful decision, but it can reveal when an efficient design treats a real group as an edge case.
After deployment, people need evidence about performance and failure. Agencies should report the number of decisions, overrides, appeals, outages, security incidents, disparate impacts, and unresolved complaints, subject to legitimate privacy limits. Oversight bodies need technical capacity and vendor access. Courts and legislatures should not accept “the system does it” as a reason. An institution remains responsible after a choice is translated into software.
Procurement Is Constitutional Design
Governments often acquire infrastructure through contracts that seem administrative but determine public power for years. A vendor may control the code, cloud, data format, security updates, and expertise needed to operate a service. Switching costs can make a contract effectively irreversible even when the agreement allows termination. Procurement is therefore constitutional design: it decides who can inspect, repair, modify, or discontinue systems through which rights are exercised.
Contracts for consequential public systems should specify data ownership and access, portability in usable formats, audit rights, security duties, incident reporting, service continuity, accessibility, records needed for appeals, and support for independent evaluation. They should require assistance with migration and prohibit secondary commercial uses not authorized by the public purpose. Proprietary software may be appropriate, but trade secrecy cannot erase the agency's duty to explain and defend a decision.
Procurement should also test the provider's dependence on other providers. A public agency may think it has selected one contractor while relying on a chain of cloud hosts, identity services, data brokers, and open-source maintainers. The chain should be mapped with contingency plans. Open standards, interoperability, escrow or access to necessary materials, and multiple qualified providers can reduce enclosure. No architecture eliminates dependency; responsible governance makes it visible and negotiable.
Strong Objection: Efficiency Requires Integration
The strongest objection is practical. Fragmented systems waste money, make people repeat their information, and prevent agencies from seeing fraud or coordinating services. Integrated platforms can be faster and cheaper. Requiring multiple approvals, local alternatives, and human fallbacks may preserve old bureaucracy while people wait for help.
Efficiency is a genuine public value, but it is not the only value. Integration can reduce friction for some people while concentrating the consequences of one error for everyone. A unified record can improve care and also expose intimate information beyond the original purpose. A shared identity can prevent duplicate payments and also exclude a person whose legal documents are inconsistent. The right response is purposeful integration: connect only needed data, limit access by role, separate incompatible purposes, and provide correction and exit routes.
Resilience need not mean recreating paper queues everywhere. It can mean a staffed telephone path, a local office able to issue a temporary credential, a read-only backup, a manual payment process, and an escalation officer. The goal is not nostalgia for friction. It is to prevent efficiency from becoming a condition in which the institution has no humane response when its assumptions fail.
Strong Objection: Code Is Only Implementation
A second objection says that elected officials make policy and engineers only implement it. Holding infrastructure politically accountable may invite courts or activists to second-guess technical choices that require expertise.
Expertise is necessary, but implementation choices have distributive effects. Choosing a mandatory app instead of a staffed counter changes who can participate. Choosing an exact address match instead of a human-confirmed match changes whose claim succeeds. Choosing a retention period changes who may later be exposed. These choices can be technically competent and still require public justification. Democratic oversight need not prescribe every line of code; it should set the purposes, rights, risk limits, review duties, and change procedures within which expertise operates.
There is also no purely technical answer to whether a false positive is acceptable, whether an appeal must pause enforcement, or whether vulnerable people deserve a non-digital route. Those are judgments about justice and authority. Engineers should be heard as experts and protected when they identify risks, but they should not be made the accidental legislature for everyone who depends on their system.
Practical Design and Governance
Public institutions should maintain an inventory of consequential systems and designate a responsible official for each. Before launch, they should document the public purpose, legal authority, affected groups, data flows, threat model, accessibility plan, fallback, retention, procurement dependencies, and appeal route. A system should not go live merely because it passed a functional test; it should show that people can understand, contest, and survive foreseeable failure.
Design reviews should ask whether the system can be paused, contained, repaired, migrated, replaced, or—when technically safe—rolled back. They should identify what happens to distributed state and to external effects that cannot be undone, including notification, reconstruction, and compensation. Release processes should include staged deployment, independent security testing, relevant impact assessment, monitoring, and post-launch review. Changes to a policy encoded in software should receive a policy record and public notice appropriate to their effect. Emergency changes should be time-limited and reviewed afterward rather than becoming a permanent shortcut.
Citizens need alternatives that are real, not merely ceremonial. Provide non-digital access for essential services, accessible formats, language support, human help, and an appeal channel independent enough to question the original team. Preserve a way to correct data and request deletion where law permits. Record decisions and versions so a reviewer can reconstruct what happened without retaining more personal information than necessary.
Democratic legitimacy also requires limits on private power. Contracts should prevent vendor lock-in, require transition assistance, and make subcontracting visible. Public officials should report material incidents and conflicts. Legislatures should fund maintenance, security, training, and review rather than approving only the launch-era purchase. A system is not cheap if its hidden costs are borne by residents who cannot obtain a benefit, challenge a record, or leave an unsafe platform.
Sources and qualifications
The theological framework draws on Gaudium et Spes 24–26; Quadragesimo Anno 79–80; Mater et Magistra 53–58; Laudato Si' 104–114; and the Catechism of the Catholic Church 1883–1885, 1905–1912, and 2293–2295. These sources affirm human dignity, participation, subsidiarity, the common good, and responsible stewardship of technical power. They do not require open source, blockchain, paper forms, or any single technical architecture. They provide principles for judging whether technology serves persons and communities.
The governance recommendations draw on administrative-law traditions, public procurement and records practice, security engineering, the OECD AI Principles, the NIST AI Risk Management Framework, and human-rights protections for participation, privacy, expression, and remedy. Agency duties, judicial review, procurement disclosure, accessibility, and data retention vary by jurisdiction. International standards are references, not a substitute for local law or professional advice. “Code as law” warns about practical effects; it does not claim that software automatically becomes enacted law.
A Political Choice That Can Still Be Revised
Software becomes politically dangerous when its choices appear inevitable. A database field looks like a fact; a default looks like convenience; a failed appeal looks like an unfortunate user error. But each may embody a decision about belonging, evidence, authority, or risk. Bringing those decisions into public view does not obstruct innovation. It gives innovation a legitimate direction and gives citizens a way to object before dependency becomes surrender.
A democratic digital institution is not one with no rules or no automation. It is one whose rules remain intelligible, whose infrastructure remains revisable, and whose authority remains answerable to the people it serves. Versioning preserves memory; remediation and remedy preserve correction; procurement preserves independence; fallback preserves human dignity; contestability preserves politics. Together they keep implementation from becoming destiny without pretending that every technical state can be undone.
Catholic social thought asks whether our arrangements leave room for persons and communities to act responsibly toward one another. That question reaches into source code, contracts, interfaces, and maintenance budgets. Society may use software without becoming its prisoner. The essential condition is that no system be allowed to convert a past technical choice into an unappealable command over the future.
Source Notes
The Council’s account of dignity, participation, social institutions, and the common good.
The principle of subsidiarity, applied here to infrastructure that can either support or absorb smaller communities.
Catholic reflection on technical power, integral human development, responsibility, and the common good.
A governance framework for identifying, measuring, managing, and monitoring risks in consequential automated systems.
International principles for transparency, accountability, robustness, human agency, and inclusive public governance of AI.
Editorial revision note
This essay completed one self-editing, cross-essay consistency, and strongest-criticism pass. Its controlling thesis was preserved while objections, qualifications, evidence limits, and practical consequences were strengthened.