A technology stack is often presented as a technical diagram, but every layer also distributes power. Devices determine who can participate. Identity determines who can be recognized. Data determines what can be remembered. Protocols determine who can coordinate. Artificial intelligence determines which judgments are automated. Governance, funding, procurement, accessibility, audit, and exit determine whether the system can be corrected or escaped.
A Catholic technology stack is therefore not a list of approved brands or a sanctification of open source. It is a way to order capabilities toward human dignity, the common good, subsidiarity, solidarity, stewardship, and truthful participation. Each layer involves tradeoffs. Local-first storage can complicate backup; federation can complicate moderation; privacy can limit analytics; accessible design can cost money; open standards can slow a launch. The point is not to deny those costs, but to decide who bears them and why.
Layer one: devices, networks, and the material world
The bottom layer is not abstract infrastructure. It is phones assembled from minerals, data centers using energy and water, repair workers, undersea cables, and people whose hands and eyes meet an interface. A responsible stack favors long support periods, repairable hardware, replaceable batteries where feasible, secure updates, low-bandwidth operation, and graceful degradation when connectivity fails. It funds accessibility rather than treating it as a special request.
There is no single correct device policy. A high-assurance medical service may need hardware-backed keys; a shelter may need a shared kiosk and paper alternative; a rural parish may need SMS and offline queues. Biometrics can help a person who cannot remember a password, but they are difficult to revoke and can impose unequal error rates. Strong encryption protects conscience and association, but recovery must be possible for people who lose a device. Good architecture states which risk it accepts instead of calling a product universally secure.
Layer two: identity, access, and the person beyond the account
Identity should be claim-based and contextual. Use open credential formats, selective disclosure, pairwise identifiers, short-lived tokens, and clear delegation. Separate authentication—who controls a credential—from authorization—what this person may do here. Keep parish, school, charity, employment, and civic contexts from becoming one involuntary profile. Provide paper, assisted, and offline paths so lack of a smartphone is not treated as lack of a person.
The governing tradeoff is between fraud resistance and exclusion. Requiring more evidence may prevent impersonation while excluding the displaced, the poor, or those whose documents were lost. A proportional design uses the least evidence necessary for the harm at stake, increases assurance only when justified, and provides human review. There should be no universal identifier whose convenience quietly converts every institution into a surveillance partner.
Layer three: data, memory, and meaning
Data architecture begins with purpose limitation. Collect only what a service needs; separate sensitive domains; encrypt in transit and at rest; restrict internal access; set deletion and archival schedules; and let people see, correct, export, and contest consequential records. Local-first patterns keep ordinary work on a device or community server, synchronizing only what must be shared. Federation lets institutions collaborate without creating a single owner of every relationship.
Local-first is not automatically private: a compromised laptop can be more exposed than a well-run service. Centralization is not automatically oppressive: a professionally secured, accountable service can protect people better than dozens of volunteers. The question is where authority, breach impact, and remedy sit. A record should have provenance, a responsible steward, an expiry or review date, and a path toward correction. Immutable logs may preserve accountability, but sensitive facts should rarely be made permanent.
Layer four: protocols for coordination
Open protocols can make participation and exit real. Use documented APIs, portable formats, cryptographic signatures where they answer a defined integrity question, and federation where separate communities need to cooperate. A protocol should specify threat assumptions, failure behavior, versioning, key recovery, abuse reporting, and governance—not merely packet syntax. Interoperability includes social interoperability: who answers a complaint when an automated exchange causes harm?
Decentralization is a tradeoff, not a sacrament. It can reduce a single point of control while increasing operational burden, fragmentation, and difficulty of coordinated safety response. A permissionless network can preserve access while enabling abuse; a moderated federation can protect vulnerable people while creating gatekeepers. Choose the smallest degree of central coordination that can actually address the risk, then make that coordination transparent and contestable.
Layer five: AI as a bounded instrument
AI belongs above accountable data and protocols, not in place of them. Retrieval should preserve citations and document versions. Models should expose uncertainty, limit tool permissions, protect sensitive prompts, and route high-stakes matters to people. Organizations need an inventory of models, documented purposes, evaluations for disparate harms, incident response, and the ability to turn off a risky feature. A model should draft or assist where its speed helps; it should not silently decide eligibility, discipline, pastoral standing, or a person's worth.
The stack should resist emotional dependency and moral outsourcing. An assistant can help a person compare options, but it should not impersonate a priest, therapist, judge, or friend. User agency means visible actions, confirmation before consequences, source inspection, memory consent, and a human appeal. “Human in the loop” is inadequate if the human has no time, context, or authority to disagree.
Layer six: governance and the boundaries of authority
Governance makes technical defaults answerable. A cooperative, diocesan network, public agency, or nonprofit may be an appropriate steward for different functions; no structure is immune to capture. Publish decision rights, conflicts, budgets, retention rules, safety policies, and change procedures. Give affected people a meaningful voice before deployment and a practical route to complain afterward. Local administrators should control ordinary settings, while a higher level supplies resources and intervenes against harms local power cannot contain.
Authority should be scoped in both code and policy. A school can manage enrollment without seeing a family's charitable history. A parish can coordinate volunteers without controlling civic identity. A vendor can process data under contract without quietly claiming the right to reuse it. Separation of duties, dual control for sensitive actions, independent oversight, and term limits for administrators keep stewardship from becoming ownership.
Interfaces, dependency, and failure ownership
Layers need contracts between them. The device layer promises secure update and an accessible fallback to the identity layer; identity promises bounded authorization to data; data promises provenance, retention, and deletion signals to protocols; protocols expose versioned events to applications; AI receives only the tools and context governance has approved. Each interface names its owner, latency and availability expectation, threat assumptions, and behavior when the next layer is unavailable. “The vendor outage caused it” is not an adequate incident report when a parish has denied a person access to food.
Dependency risk should be measured as a moral as well as a financial liability. Record which key, format, cloud region, model, and administrator a service depends on; rehearse replacement; and cap the blast radius of a compromised component. A cloud provider can host encrypted workloads without owning the community's identifiers. A model provider can supply inference without receiving raw pastoral notes. Failure ownership remains with the organization that chose to expose a person to the system, even when contracts allocate technical tasks elsewhere.
Build, buy, or federate
Build when the capability expresses a distinctive duty—such as a parish's safeguarding workflow—and the institution can maintain security for its full life. Buy a commodity when a specialist can provide stronger patching, accessibility, and reliability than a small team, provided the contract preserves data boundaries and exit. Federate when several communities need a common protocol or shared support while retaining separate decision rights. Build gives control but creates maintenance debt; buying accelerates deployment but risks lock-in; federation spreads expertise but requires agreement about versions, incidents, and appeals.
A procurement board should score all three options against five-year cost, staffing, security evidence, accessibility, migration effort, and who can halt harmful behavior. It should reject a cheap platform whose export is unusable or whose terms permit secondary surveillance. It should also reject an elegant local project that no one can patch after its volunteer maintainer leaves. The decision is revisited when the purpose, risk, or financial model changes.
Funding and procurement are architecture
A system funded only by surveillance will eventually surveil. Sustainable alternatives include public budgets, cooperative dues, philanthropic grants with transparent conditions, and service fees tied to real support rather than behavioral extraction. A free product may be costly in privacy, labor, or lock-in. Financial models should disclose externalities and reserve money for updates, accessibility, security, support, incident response, and end-of-life migration.
Procurement should require open documentation, export in usable formats, security updates, accessibility conformance, data minimization, subprocessor disclosure, breach duties, service-level commitments, and a tested exit plan. Total cost of ownership includes training, translation, repair, human review, and the time of people who cannot use a default interface. Small community institutions may need shared procurement and technical assistance so that “choice” is not merely permission to choose an unaffordable vendor.
Accessibility, audit, and exit
Accessibility is not a final compliance pass. People with visual, auditory, motor, cognitive, linguistic, or economic differences should participate in requirements, testing, and governance. Follow WCAG principles, but also test with real users, screen readers, captions, keyboard navigation, plain language, translation, low literacy, and intermittent power. Preserve assisted pathways without exposing a disabled person to unnecessary surveillance or humiliation.
Audit must examine outcomes and authority, not only code. Keep tamper-evident records of sensitive administrative actions, conduct independent security and privacy assessments, publish understandable summaries, and give people notice when a system affects them. Audit trails are not explanations, and a fairness score is not justice. Reviewers need access to evidence, time to investigate, and power to pause or change the system.
Exit is an architectural requirement. Export a person's own records in documented formats; preserve references and consent where lawful; provide migration tools; and give institutions a supported shutdown path. A vendor that makes departure impossible has acquired authority without consent. Exit cannot erase another person's private data, safety record, or due process, so portability needs careful boundaries rather than the promise that everything can be copied everywhere.
A deployment sequence, not a grand replacement
A community should not attempt to replace its entire information environment at once. First name the human problem and the people who bear its cost. Then map current data flows, identify the smallest useful service, and write a failure and exit plan before selecting a vendor. Build an accessible prototype with paper and assisted alternatives. During a pilot, measure who cannot enter, who must do unpaid work, how long correction takes, and whether the promised privacy survives ordinary staff behavior.
Only after those tests should an organization expand integrations. Version interfaces, retain a manual fallback, and set a date at which leaders must review the evidence rather than assuming success. A diocesan or civic network can share security expertise and common tooling while allowing local communities to set appropriate practices. This gradual path may appear less visionary than a single platform, but it makes the stack accountable to lived relationships and gives people a chance to refuse harmful defaults before they become infrastructure.
Failure modes and objections
One failure is “Catholic” branding used to conceal ordinary extraction. A cross-shaped logo does not make a tracking system humane. Another is product sanctification: treating open source, blockchain, local-first software, or AI as morally good by category. Every tool can serve dignity or domination depending on its purpose, incentives, and safeguards. A third is stack fragmentation, in which local autonomy produces incompatible services and pushes the burden onto users.
Critics may say this stack is too expensive and slow for communities with urgent needs. The objection is serious. A minimal, safe service today can be better than an ideal system that never ships. The answer is staged deployment: start with a narrow purpose, preserve manual alternatives, publish known limitations, and budget for repair before expansion. Another critic may say central platforms are simply more efficient. They often are for a while; the question is whether that efficiency is purchased by unpriced dependency, exclusion, or lost agency.
Make the tradeoff concrete with reference profiles rather than a universal topology: a small parish, a public-benefit service, and a high-risk safeguarding service will have different staffing, fallback, and acceptable-centralization assumptions. For each, record a build/buy/federate decision, five-year operating cost, dependency owners, service levels, migration path, and exercises for vendor outage, recovery, breach, and appeal. Evaluate accessibility, correction time, breach blast radius, energy, cost, and successful exit. A centralized specialist may be safer for one layer and a federated arrangement safer for another. The Catholic ordering does not select a topology; it requires that the chosen one disclose who bears its failures and remains answerable.
Sources and qualifications
The Catholic account draws on the Compendium of the Social Doctrine of the Church, Gaudium et Spes, Laudato Si',Fratelli Tutti, Dignitas Infinita, and the principles of subsidiarity, solidarity, and the common good. Technical reference points include NIST Cybersecurity and Privacy Frameworks, NIST SP 800-63, the W3C Verifiable Credentials and ActivityPub specifications, WCAG 2.2, ISO/IEC 27001 and 27701, the OWASP ASVS and LLM guidance, and the NIST AI Risk Management Framework. These standards are aids, not guarantees. Sectoral law, labor rights, safeguarding obligations, and local expertise remain necessary.
Synthesis: stack the conditions of freedom
A Catholic technology stack would not be recognizable by a favorite programming language. It would be recognizable by the questions answered at every layer: Who is included? Who bears the risk? What can remain local? What is remembered? Who may act? Who can correct the record? How does a community pay for care? Can a person use the system accessibly, audit its power, and leave?
The result is not frictionless technology. It is technology whose friction is placed where it protects a person rather than where it hides a cost. Devices, credentials, data, protocols, AI, governance, and funding become instruments of human communion only when they remain answerable to the people and communities they serve.
Source Notes
The principal synthesis for dignity, the common good, subsidiarity, solidarity, participation, and stewardship.
Catholic reflection on technology, ecology, material systems, and integral human development.
A risk-management framework for identifying, protecting, detecting, responding to, and recovering from cybersecurity risk.
A framework for privacy risk management, governance, control, communication, and data protection.
An open model for portable, bounded credentials and attestations across identity layers.
The current W3C accessibility standard informing perceivable, operable, understandable, and robust interfaces.
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.