diff --git a/.github/workflows/deploy-docs.yml b/.github/workflows/deploy-docs.yml index d607434..0541941 100644 --- a/.github/workflows/deploy-docs.yml +++ b/.github/workflows/deploy-docs.yml @@ -25,10 +25,9 @@ jobs: run: | # All governed documents: directory/filename (without .md) DOCS=( - "ai-governance/ai-vetting-criteria" - "ai-governance/fragmented-catholic-ai-governance" - "ai-governance/governance-as-code-catholic-ai" - "ai-governance/trusted-synthetic-data-ministry-ai" + "research/fragmented-catholic-digital-governance" + "research/governance-as-code-catholic-technology" + "research/trusted-data-infrastructure-catholic-ministry" "project-governance/definitions" "project-governance/project-types" "project-governance/lifecycle" @@ -73,6 +72,24 @@ jobs: echo "changed_docs=$CHANGED_DOCS" >> "$GITHUB_OUTPUT" + # Detect deleted governance documents (stale pages to remove) + DELETED_DOCS="" + if [ "$DEPLOY_ALL" != true ] && [ -n "$DIFF_BASE" ]; then + DELETED=$(git diff --name-only --diff-filter=D "$DIFF_BASE" HEAD 2>/dev/null || echo "") + for FILE in $DELETED; do + case "$FILE" in + # Skip non-governance markdown files + README.md|RELEASING.md|CONTRIBUTING.md|CHANGELOG.md|*/README.md) continue ;; + */*.md) + DOC="${FILE%.md}" + echo " Deleted: $FILE" + DELETED_DOCS="${DELETED_DOCS:+$DELETED_DOCS }${DOC}" + ;; + esac + done + fi + echo "deleted_docs=$DELETED_DOCS" >> "$GITHUB_OUTPUT" + - name: Install pandoc uses: pandoc/actions/setup@v1.1.1 @@ -86,14 +103,13 @@ jobs: run: | # Document titles keyed by directory/basename declare -A DOC_TITLES=( - ["ai-governance/ai-vetting-criteria"]="CDCF Project Vetting Criteria: AI Tools" - ["ai-governance/fragmented-catholic-ai-governance"]="Fragmented Catholic AI Governance at Scale" - ["ai-governance/governance-as-code-catholic-ai"]="Governance-as-Code for Catholic AI Agent Deployment" - ["ai-governance/trusted-synthetic-data-ministry-ai"]="Trusted Synthetic Data for Ministry-Scale AI" + ["research/fragmented-catholic-digital-governance"]="Fragmented Catholic Digital Governance at Scale" + ["research/governance-as-code-catholic-technology"]="Governance-as-Code for Catholic Technology Deployment" + ["research/trusted-data-infrastructure-catholic-ministry"]="Trusted Data Infrastructure for Catholic Ministry" ["project-governance/definitions"]="CDCF Governance Definitions" ["project-governance/project-types"]="CDCF Project Types: Foundation Projects and Community Projects" ["project-governance/lifecycle"]="CDCF Project Lifecycle" - ["project-governance/project-vetting-criteria"]="CDCF Project Vetting Criteria: General Framework" + ["project-governance/project-vetting-criteria"]="CDCF Project Vetting Criteria" ["project-governance/committees"]="CDCF Governance Bodies" ["standards/overview"]="CDCF Standards: Overview" ["standards/committees"]="CDCF Standards Committees" @@ -101,8 +117,8 @@ jobs: # Parent page slugs for each section declare -A SECTION_PARENTS=( - ["ai-governance"]="ai-governance" ["project-governance"]="project-governance" + ["research"]="research" ["standards"]="standards" ) @@ -228,6 +244,78 @@ jobs: echo "" echo "All translations complete." + - name: Remove stale WordPress pages + if: steps.changes.outputs.deleted_docs != '' + env: + WP_REST_URL: ${{ vars.WP_REST_URL }} + WP_APP_USERNAME: ${{ secrets.WP_APP_USERNAME }} + WP_APP_PASSWORD: ${{ secrets.WP_APP_PASSWORD }} + run: | + STALE_SECTIONS=() + + for DOC in ${{ steps.changes.outputs.deleted_docs }}; do + SECTION=$(dirname "$DOC") + BASENAME=$(basename "$DOC") + if [ "$SECTION" = "standards" ]; then + SLUG="standards-${BASENAME}" + else + SLUG="$BASENAME" + fi + + echo "Checking for stale page: ${SLUG}..." + EXISTING=$(curl -s \ + -u "$WP_APP_USERNAME:$WP_APP_PASSWORD" \ + "$WP_REST_URL/wp/v2/pages?slug=${SLUG}&status=publish,draft") + + PAGE_ID=$(echo "$EXISTING" | jq -r 'if type == "array" then .[0].id // empty else empty end') + + if [ -n "$PAGE_ID" ] && [ "$PAGE_ID" != "null" ]; then + echo " Trashing page ID $PAGE_ID (slug: ${SLUG})..." + HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' -X DELETE \ + -u "$WP_APP_USERNAME:$WP_APP_PASSWORD" \ + "$WP_REST_URL/wp/v2/pages/$PAGE_ID") + if [[ "$HTTP_CODE" -lt 300 ]]; then + echo " Trashed." + else + echo " Warning: delete returned HTTP $HTTP_CODE" + fi + else + echo " No WordPress page found — skipping." + fi + + # Track sections that had deletions + if [[ ! " ${STALE_SECTIONS[*]} " =~ " ${SECTION} " ]]; then + STALE_SECTIONS+=("$SECTION") + fi + done + + # If an entire section directory no longer exists, trash the parent page + for SECTION in "${STALE_SECTIONS[@]}"; do + if [ ! -d "$SECTION" ]; then + echo "Section '${SECTION}' no longer exists — checking for stale parent page..." + PARENT=$(curl -s \ + -u "$WP_APP_USERNAME:$WP_APP_PASSWORD" \ + "$WP_REST_URL/wp/v2/pages?slug=${SECTION}&status=publish,draft") + + PARENT_ID=$(echo "$PARENT" | jq -r 'if type == "array" then .[0].id // empty else empty end') + + if [ -n "$PARENT_ID" ] && [ "$PARENT_ID" != "null" ]; then + echo " Trashing parent page ID $PARENT_ID (slug: ${SECTION})..." + HTTP_CODE=$(curl -s -o /dev/null -w '%{http_code}' -X DELETE \ + -u "$WP_APP_USERNAME:$WP_APP_PASSWORD" \ + "$WP_REST_URL/wp/v2/pages/$PARENT_ID") + if [[ "$HTTP_CODE" -lt 300 ]]; then + echo " Trashed." + else + echo " Warning: delete returned HTTP $HTTP_CODE" + fi + fi + fi + done + + echo "" + echo "Stale page cleanup complete." + - name: Setup Node.js uses: actions/setup-node@v6 with: diff --git a/.gitignore b/.gitignore index c2658d7..b947077 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ node_modules/ +dist/ diff --git a/README.md b/README.md index 97d6734..bb66c6a 100644 --- a/README.md +++ b/README.md @@ -24,39 +24,36 @@ A working repository for governance documentation supporting the **Catholic Digi This repository holds the policy frameworks, evaluation criteria, and research documentation that inform how the CDCF reviews, incubates, and graduates technology projects. It is modeled on established foundation governance (such as the Apache Software Foundation) but is uniquely grounded in Catholic Social Teaching and Canon Law. -The documentation is organized into a general project governance framework, applicable to all technology projects, and specialized domain-specific criteria (starting with AI -governance). +The documentation is organized into a unified project governance framework (with domain-specific extensions for AI integrated inline), supplementary research memos, and standards +for canonical data interoperability. --- ## Document Stack -### General Project Governance +### Project Governance The core frameworks for any project seeking CDCF endorsement. -| Document | Type | Description | -| :------------------------------------------------------------------------------ | :--------- | :------------------------------------------------------------------------------------- | -| [project-vetting-criteria.md](./project-governance/project-vetting-criteria.md) | **Policy** | The foundational 8 criteria for any CDCF project. | -| [lifecycle.md](./project-governance/lifecycle.md) | Procedure | Definition of the stages from proposal through incubation, graduation, and retirement. | -| [committees.md](./project-governance/committees.md) | Structure | Governance bodies: Board of Directors, TCSC, and PMCs. | -| [project-types.md](./project-governance/project-types.md) | Policy | Distinction between Foundation Projects and Community Projects. | -| [definitions.md](./project-governance/definitions.md) | Glossary | Shared vocabulary for CDCF governance and vetting. | +| Document | Type | Description | +| :------------------------------------------------------------------------------ | :--------- | :-------------------------------------------------------------------------------------------------------- | +| [project-vetting-criteria.md](./project-governance/project-vetting-criteria.md) | **Policy** | The foundational 8 criteria for any CDCF project, with AI domain extensions integrated inline. | +| [lifecycle.md](./project-governance/lifecycle.md) | Procedure | Definition of the stages from proposal through incubation, graduation, and retirement. | +| [committees.md](./project-governance/committees.md) | Structure | Governance bodies: Board of Directors, TCSC, and PMCs. | +| [project-types.md](./project-governance/project-types.md) | Policy | Distinction between Foundation Projects and Community Projects. | +| [definitions.md](./project-governance/definitions.md) | Glossary | Shared vocabulary for CDCF governance and vetting. | --- -### Specialized Domain Governance +### Research -Domain-specific extensions to the general framework. +Supplementary research memos informing the design of the vetting criteria. -#### AI Governance - -| Document | Type | Description | -| :--------------------------------------------------------------------------------------------- | :------------ | :-------------------------------------------------------------------------- | -| [ai-vetting-criteria.md](./ai-governance/ai-vetting-criteria.md) | **Policy** | Operational vetting criteria for AI tools, extending the general framework. | -| [fragmented-catholic-ai-governance.md](./ai-governance/fragmented-catholic-ai-governance.md) | Research memo | The urgency of shared AI governance standards. | -| [governance-as-code-catholic-ai.md](./ai-governance/governance-as-code-catholic-ai.md) | Research memo | Machine-enforceable deployment governance architecture. | -| [trusted-synthetic-data-ministry-ai.md](./ai-governance/trusted-synthetic-data-ministry-ai.md) | Research memo | Synthetic data infrastructure for ministry-scale AI. | +| Document | Type | Description | +| :------------------------------------------------------------------------------------------ | :------------ | :------------------------------------------------------ | +| [fragmented-catholic-digital-governance.md](./research/fragmented-catholic-digital-governance.md) | Research memo | The urgency of shared digital governance standards. | +| [governance-as-code-catholic-technology.md](./research/governance-as-code-catholic-technology.md) | Research memo | Machine-enforceable deployment governance architecture. | +| [trusted-data-infrastructure-catholic-ministry.md](./research/trusted-data-infrastructure-catholic-ministry.md) | Research memo | Trusted data infrastructure for Catholic ministry. | --- diff --git a/RELEASING.md b/RELEASING.md new file mode 100644 index 0000000..15c67ca --- /dev/null +++ b/RELEASING.md @@ -0,0 +1,144 @@ +# Releasing + +This document describes how governance documents are built, deployed, and released. + +## Overview + +The release pipeline is driven by the GitHub Actions workflow +`.github/workflows/deploy-docs.yml`. It triggers on: + +- **Tag push** matching `v*` (e.g. `v0.2`) -- deploys only documents changed + since the previous tag. +- **Manual dispatch** (`workflow_dispatch`) -- deploys all documents. + +A single workflow run performs four stages in order: + +1. Deploy changed documents to WordPress +2. Translate deployed pages +3. Build standalone HTML and combined PDF artifacts +4. Create (or update) a GitHub release with those artifacts + +## Prerequisites + +The following repository secrets and variables must be configured in GitHub: + +| Name | Type | Purpose | +| :------------------ | :------- | :----------------------------------------------- | +| `WP_REST_URL` | Variable | Base URL of the WordPress REST API | +| `WP_APP_USERNAME` | Secret | WordPress application password username | +| `WP_APP_PASSWORD` | Secret | WordPress application password | + +The WordPress site must also expose a custom REST endpoint +(`cdcf/v1/translate`) that accepts a `source_id` and `target_lang` for the +translation step. + +## How to release + +### 1. Prepare the branch + +Ensure all changes are merged to `main` and that quality checks pass: + +```bash +npm run lint:md # 0 errors expected +npm run build:html # standalone HTML files in dist/ +npm run build:pdf # combined PDF in dist/ +``` + +### 2. Tag and push + +```bash +git tag v0.X +git push origin v0.X +``` + +This triggers the deploy workflow automatically. + +Alternatively, run the workflow manually from the GitHub Actions tab +(**Run workflow** on the `main` branch). Manual runs deploy all documents and +auto-increment the version tag. + +### 3. What the workflow does + +#### Stage 1 -- WordPress deployment + +- Compares the tagged commit against the previous tag to determine which + `.md` files changed. +- Converts each changed document from Markdown to HTML using `pandoc` with + the Lua filter `scripts/fix-internal-links.lua` (which rewrites internal + `.md` links for the target output format). +- Creates or updates the corresponding WordPress page via the REST API, + organized under parent pages (`project-governance`, `research`, `standards`). + +#### Stage 1b -- Stale page cleanup + +- Uses `git diff --diff-filter=D` between tags to detect governance `.md` + files that were deleted or renamed since the previous release. +- Derives the WordPress slug for each deleted file (using the same logic as + deployment) and trashes the corresponding page. +- If an entire section directory no longer exists (e.g. `ai-governance/` was + removed), the parent page is also trashed. +- Pages are moved to the WordPress trash (not permanently deleted), so they + can be recovered if needed. +- This step only runs for tag-triggered deploys (not manual dispatch, which + has no previous tag to compare against). + +#### Stage 2 -- Translation + +- Each newly deployed page is translated into **it**, **es**, **fr**, **pt**, + and **de** via the `cdcf/v1/translate` endpoint. + +#### Stage 3 -- Build artifacts + +- `npm run build:html` (`scripts/build-standalone-html.sh`) -- produces one + self-contained HTML file per document in `dist/`, each with a navigation + sidebar linking to the other documents. +- `npm run build:pdf` (`scripts/build-combined-pdf.sh`) -- concatenates all + documents into a single Markdown file, converts to standalone HTML, then + renders a paginated PDF using `pagedjs-cli`. + +Both scripts use `scripts/docs-print.css` for styling and +`scripts/fix-internal-links.lua` for link rewriting. + +#### Stage 4 -- GitHub release + +- Creates a GitHub release titled **Governance Docs vX.Y** with all + `dist/*.html` and `dist/*.pdf` files attached. +- If the release already exists (e.g. re-run), assets are uploaded with + `--clobber`. + +## Local builds + +You can build artifacts locally without deploying: + +```bash +npm install # first time only +npm run build:html # dist/*.html +npm run build:pdf # dist/cdcf-governance-docs.pdf (requires pagedjs-cli) +``` + +The PDF build requires Google Chrome or Chromium installed locally +(`pagedjs-cli` uses it for rendering). Set `PUPPETEER_EXECUTABLE_PATH` if +the binary is not in the default location. + +## Document inventory + +The following documents are included in builds and deployments: + +| Section | File | +| :----------------- | :----------------------------------------------- | +| Project Governance | `project-governance/project-vetting-criteria.md` | +| Project Governance | `project-governance/lifecycle.md` | +| Project Governance | `project-governance/committees.md` | +| Project Governance | `project-governance/project-types.md` | +| Project Governance | `project-governance/definitions.md` | +| Research | `research/fragmented-catholic-digital-governance.md` | +| Research | `research/governance-as-code-catholic-technology.md` | +| Research | `research/trusted-data-infrastructure-catholic-ministry.md` | +| Standards | `standards/overview.md` | +| Standards | `standards/committees.md` | + +To add a new document, update the `DOCS` array in all three places: + +1. `.github/workflows/deploy-docs.yml` (lines 27-38 and 87-98) +2. `scripts/build-standalone-html.sh` (lines 10-21) +3. `scripts/build-combined-pdf.sh` (lines 12-24) diff --git a/ai-governance/ai-vetting-criteria.md b/ai-governance/ai-vetting-criteria.md deleted file mode 100644 index 3e0b2c9..0000000 --- a/ai-governance/ai-vetting-criteria.md +++ /dev/null @@ -1,337 +0,0 @@ -# CDCF Project Vetting Criteria: AI Tools - -| | | -| :--------------- | :-------------------------------------------------------------------------------------------------------------------------------- | -| **Version** | v0.1 (draft for community review) | -| **Scope** | AI-assisted tools submitted for CDCF incubation and graduation | -| **Relationship** | This is a domain-specific extension of the [General Project Vetting Criteria](../project-governance/project-vetting-criteria.md). | - ---- - -## Table of Contents - -1. [Purpose and Rationale](#purpose-and-rationale) -2. [Gate 1: Incubation Acceptance](#gate-1-incubation-acceptance) - - [Criterion 1: Mission Alignment and Canonical Scope](#criterion-1-mission-alignment-and-canonical-scope) - - [Criterion 2: Human Accountability Architecture](#criterion-2-human-accountability-architecture) - - [Criterion 3: Transparency of Scope and Operation](#criterion-3-transparency-of-scope-and-operation) - - [Criterion 4: Independent Validation of Claimed Capabilities](#criterion-4-independent-validation-of-claimed-capabilities) - - [Criterion 5: Subgroup Performance and Vulnerable Population Review](#criterion-5-subgroup-performance-and-vulnerable-population-review) - - [Criterion 6: Deployment Governance Specification](#criterion-6-deployment-governance-specification) -3. [Gate 2: Graduation to Active CDCF Project Status](#gate-2-graduation-to-active-cdcf-project-status) - - [Criterion 7: Documentation for Independent Deployment and Data Stewardship](#criterion-7-documentation-for-independent-deployment-and-data-stewardship) - - [Criterion 8: Governance, Maintenance, and Subsidiarity Compatibility](#criterion-8-governance-maintenance-and-subsidiarity-compatibility) -4. [Grounding in Catholic Teaching and Canonical Tradition](#grounding-in-catholic-teaching-and-canonical-tradition) -5. [Relationship to the Broader Governance Research](#relationship-to-the-broader-governance-research) -6. [An Invitation to Iterate](#an-invitation-to-iterate) -7. [Bibliography](#bibliography) - ---- - -## Purpose and Rationale - -Catholic institutions serve tens of millions of people across healthcare, education, social services, and parish life. They are actively evaluating and deploying AI tools to do -this work more effectively, and they are doing so without a shared, canonical standard for what responsible Catholic deployment looks like. The consequence is fragmentation: -dioceses, school systems, and Catholic Charities agencies operating under incompatible evaluation criteria for structurally identical use cases, with tools that touch sensitive -populations entering production without a documented discernment process. - -This document establishes what "vetted" means for AI tools accepted into the Catholic Digital Commons Foundation. Its foundational premise is practical and specific: **the humans -inside a system determine whether the governance holds.** Policies, principles, and frameworks carry weight only when they are traceable to named individuals with real authority -and real accountability. In Catholic institutional life, that premise has deep roots. The Church teaches that human intelligence is an essential aspect of being created in the -image of God, and that technological innovation represents a participation in the divine act of creation.[^1] Because every design choice "expresses a vision of humanity," -developers carry an obligation to build systems that "reflect justice, solidarity, and a genuine reverence for life."[^2] These criteria translate that obligation into an -operational standard that developers, dioceses, and ecclesial advisors can apply consistently. - -The criteria are organized around two evaluation gates. **Gate 1** governs acceptance into incubation. **Gate 2** governs graduation to active CDCF project status. A project -advances through Gate 2 only after satisfying Gate 1 in full. - -| Gate | Stage | Criteria | Requirement | -| :--------- | :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------ | -| **Gate 1** | Incubation Acceptance | C1 Mission Alignment · C2 Human Accountability · C3 Transparency · C4 Independent Validation · C5 Subgroup Performance · C6 Deployment Governance | All six required | -| **Gate 2** | Graduation to Active Status | C7 Documentation and Data Stewardship · C8 Governance and Subsidiarity | Both required; Gate 1 must remain satisfied | - ---- - -## Gate 1: Incubation Acceptance - -> All six criteria are required for incubation acceptance. A project satisfying five of six criteria remains in pre-submission dialogue until the sixth is resolved. - ---- - -### Criterion 1: Mission Alignment and Canonical Scope - -The tool must serve a purpose coherent with the Church's evangelizing mission and with Catholic Social Teaching's account of human dignity, the common good, and subsidiarity. Tools -with the potential to serve any parish, diocese, school, or ministry facing a structurally similar need take priority over tools designed for a single institution's bespoke -requirements. - -**Canonical boundary conditions.** Certain AI applications fall outside the scope of CDCF endorsement regardless of technical quality. The doctrinal basis for these boundaries is -precise. The Church distinguishes human intelligence (understood as a synthesis of _intellectus_ (the intuitive grasp of truth) and _ratio_ (discursive reasoning) belonging to a -person composed of body and soul) from artificial statistical inference, which processes data without the capacity to think in any theologically meaningful sense.[^1] Because human -beings are ordered by their nature to interpersonal communion, and because the sacraments are incarnational realities rooted in the unity of body and soul, AI systems are -constitutively incapable of mediating sacramental grace or spiritual direction. - -The following applications are disqualifying: - -- Tools that simulate sacramental functions, including confession, absolution, or spiritual direction -- Tools that present AI-generated content as authoritative Church teaching without explicit human theological review -- Tools that assign a clerical identity, title, or visual presentation suggesting ordained status to an AI system - -These boundaries derive from documented failures in Catholic AI deployment. In April 2024, Catholic Answers launched "Father Justin," an AI chatbot presented as a priest-figure. -The system required rapid withdrawal within the first days of launch after it presented itself as a priest and claimed it could administer sacraments.[^3] A shared boundary -condition defined in advance would have identified this application as out of scope before a single line of code shipped. - -**Evaluation question:** Could this tool serve the universal Church, or does its value proposition depend on institutional specificity that constrains its broader applicability? - ---- - -### Criterion 2: Human Accountability Architecture - -Every consequential output the tool produces must be attributable to a named, accountable human being, a specific person identified by role and institutional position, who carries -responsibility for that output and who can be held to account by the persons affected. Accountability distributed across a committee without a named decision owner falls short of -this criterion. - -The doctrinal grounding is unambiguous. Decision-making about the lives of persons "must always be left to the human person."[^1] As Pope Francis stated directly: "We would condemn -humanity to a future without hope if we took away people's ability to make decisions about themselves and their lives, by dooming them to depend on the choices of machines." -Maintaining proper human control over AI-mediated decisions is a binding moral requirement; "human dignity itself depends on it."[^1] - -This requirement also operationalizes Canon 627 of the Code of Canon Law, which establishes that superiors must use councils with defined consent and counsel obligations, and that -consequential authority is always tied to specific individuals operating within defined systems of consultation.[^4] In Catholic governance, authority is never an autonomous or -untraceable mechanism. - -The structural failure documented in the Australian Robodebt scheme (2016–2019) illustrates what the removal of named human accountability produces at scale: hundreds of thousands -of unlawful debt notices and multiple deaths among vulnerable welfare recipients, attributed by the Royal Commission directly to the absence of human review from consequential -decisions about individuals.[^5] - -**Evaluation questions:** - -- Can a person affected by this tool's output identify who made the decision and through what process? -- Does the tool's design make human override clear, documented, and reversible? - ---- - -### Criterion 3: Transparency of Scope and Operation - -The submitter must provide technically accurate documentation of what the tool does, what data it ingests, who is affected by its outputs, what decisions it informs or makes, and -where its operational boundaries lie. This documentation must be sufficient for an independent technical reviewer to assess the tool's actual behavior without relying on vendor -marketing materials. - -The Magisterium is explicit that the "inherent dignity of each human being and the fraternity that binds us together" must serve as the "indisputable criteria for evaluating new -technologies before they are employed."[^1] Evaluation requires information. A tool whose operation cannot be independently described cannot be evaluated against those criteria. - -For AI tools that involve automated or algorithmically-assisted decision-making about people, including hiring, resource allocation, triage, content recommendation, and risk -assessment, this criterion additionally requires: - -- Disclosure of training data sources and known distributional limitations -- Documentation of any independent audits or evaluations conducted -- Clear description of which decisions the tool makes autonomously and which require human review - -The absence of this documentation signals that the submitter has work remaining before an informed deployment decision is possible. CDCF endorsement of an undocumented tool would -expose Catholic institutions to the same opacity risks that produced systemic bias in the COMPAS criminal sentencing algorithm, where risk scores were found to be nearly twice as -likely to falsely flag Black defendants as high risk compared to white defendants, before institutional accountability mechanisms were engaged.[^6] - ---- - -### Criterion 4: Independent Validation of Claimed Capabilities - -The submitter must provide evidence that the tool's claimed capabilities have been evaluated against sources independent of the vendor or developer. Vendor documentation, marketing -materials, and internal testing reports are inputs to this review; independent validation stands apart from them. - -Acceptable forms of independent validation include: - -| Validation Type | Description | -| ------------------------------ | ----------------------------------------------------- | -| Third-party technical audit | External assessment of system behavior and claims | -| Peer-reviewed evaluation | Published academic or professional review | -| Published benchmarking | Results from recognized evaluation frameworks | -| Documented red-team assessment | Structured adversarial testing with recorded findings | - -Where such validation is pending, the submitter must disclose that explicitly and provide a concrete plan and timeline for obtaining it. A project in active pursuit of independent -validation may be accepted into incubation with this criterion marked as a condition of graduation rather than a barrier to entry. - -The standard applied here is proportionate to stakes. A tool that assists with internal scheduling carries different validation requirements than a tool that informs hiring -decisions, student placement, or access to social services. The CDCF review process applies judgment accordingly. - ---- - -### Criterion 5: Subgroup Performance and Vulnerable Population Review - -The submitter must demonstrate that the tool's performance has been examined across the specific populations it will affect, with particular attention to groups underrepresented in -typical training datasets or carrying heightened vulnerability to algorithmic harm. - -The Magisterium defines algorithmic bias as "systematic and consistent errors in computer systems that may disproportionately prejudice certain groups in unintended ways."[^1] -Catholic institutions disproportionately serve populations that commercial AI development pipelines have historically underrepresented: - -- The elderly and people with disabilities -- Recent immigrants and non-English-speaking communities -- Communities in poverty and populations in rural or underserved areas - -Deploying tools without examining subgroup performance in these populations is inconsistent with the Church's preferential option for the poor and vulnerable, and it is a -governance failure regardless of aggregate accuracy metrics. - -Pope Leo XIV identifies the risk precisely: AI development becomes a moral failure when it produces systems that allow human beings to become "merely passive consumers of content -generated by artificial technology," eroding the capacity to "reflect, choose freely, love unconditionally and enter into authentic relationships."[^7] Tools that systematically -degrade outcomes for vulnerable populations accelerate exactly that erosion for the people with the least capacity to resist it. - -This criterion requires either documented subgroup performance analysis or an explicit acknowledgment of its absence paired with a concrete plan to obtain it. A submitter who has -engaged these questions with rigor and documented both the evidence and the gaps satisfies this criterion. - ---- - -### Criterion 6: Deployment Governance Specification - -The submitter must specify the governance conditions under which the tool will operate. This criterion addresses the consequential gap between a tool that is technically sound in -isolation and one that is responsibly deployed in an institutional context. - -**Required elements:** - -| Element | Description | -| ------------------------ | ----------------------------------------------------------------------- | -| Decision authority level | Parish, diocese, institution, or board; clearly mapped | -| Escalation conditions | Defined triggers requiring higher authority involvement | -| Human review triggers | Thresholds at which outputs require human examination before action | -| Appeal process | Process by which affected persons can contest an AI-influenced decision | - -The canonical grounding for these requirements is specific. Canon 1609 dictates that judges in a collegiate tribunal must submit written conclusions with reasons in law and in -fact, followed by structured discussion. Judges retain the right to withdraw from an original conclusion and to demand that dissent be transmitted to a higher tribunal.[^8] This -canonical standard establishes that Catholic decision-making requires conscious reasoning, the capacity to revise judgments, and transparent mechanisms for appeal; a deployment -governance specification must preserve these capacities in human hands. - -This criterion draws on the governance-as-code design pattern, in which deployment policies are expressed as machine-readable, auditable specifications rather than policy documents -that exist separately from the systems they govern. A mature implementation treats the gate decision itself as the primary artifact: a structured record assembling evidence, -confidence levels, named ownership, identified gaps, and explicit rationale before any downstream commitment is made. The decision states are specific and bounded: **go, -conditional-go, no-go, and defer**, each carrying distinct documentation requirements and escalation obligations. Full technical implementation at this level of rigor is -aspirational rather than required at the incubation stage. What is required is that the governance specification exists as a written, reviewable document, and that the tool's -architecture is compatible with its enforcement as institutional capacity develops. - ---- - -## Gate 2: Graduation to Active CDCF Project Status - -> Graduation requires that Gate 1 criteria remain satisfied in full and that the following two additional requirements are met. These requirements address operational readiness: -> the difference between a project that performs well in a controlled context and one that Catholic institutions can adopt, maintain, and trust at scale. - ---- - -### Criterion 7: Documentation for Independent Deployment and Data Stewardship - -The project must carry documentation sufficient for a Catholic institution to evaluate, configure, deploy, and support the tool without direct involvement from the original -submitter. This includes technical documentation, user-facing guidance, and explicit documentation of the governance specification required under Criterion 6. - -**The deployment test:** Could the director of technology at a diocesan schools office, working with their team and without access to the project's authors, deploy this tool -responsibly within 90 days? - -Data stewardship requirements are proportionate to the tool's risk profile. Tools that handle personal data must meet the following requirements: - -| Data Type | Compliance Requirement | -| ------------------------- | --------------------------------------------------------------------- | -| Health information | HIPAA compliance; data minimization approach documented | -| Student records | FERPA compliance; retention and deletion procedures specified | -| Sacramental data | Diocesan data governance policies; access controls documented | -| Data pertaining to minors | Enhanced protections; explicit consent and breach response procedures | -| Financial information | Applicable state and federal law; audit trail requirements | - -For AI tools specifically, this criterion extends to training data governance. A tool trained on data from Catholic institutions carries an obligation to those institutions and to -the populations they serve. The terms under which that data was used, and the terms under which it may be used in future model updates, must be disclosed and evaluated as part of -the graduation review. - ---- - -### Criterion 8: Governance, Maintenance, and Subsidiarity Compatibility - -The project must have a defined and documented process for ongoing maintenance, version control, vulnerability response, and community governance. A named maintainer or maintainer -team must accept public accountability for the project going forward. - -The tool must be deployable at the appropriate level of ecclesial authority, whether parish, diocese, or institution, without requiring centralized control that would compromise -subsidiarity. The Church's understanding of subsidiarity is precise on this point: it is a guarantee that each level of authority retains its proper duties and rights regarding the -common good, rather than a simple delegation of decisions to the lowest available level, and it ensures that no larger entity absorbs the legitimate initiative and responsibility -of smaller ones.[^9] Local communities must be able to configure the tool for their context, and that configuration capacity must be architecturally genuine, requiring no override -of the tool's core accountability, safety, or governance design in order to function. - -_Antiqua et Nova_ (§42) is explicit that the responsibility for managing AI wisely "pertains to every level of society, guided by the principle of subsidiarity."[^1] A tool that -functions only under conditions of centralized administration concentrates authority in ways that violate this principle and undermine the ecclesial structure the CDCF exists to -serve. - ---- - -## Grounding in Catholic Teaching and Canonical Tradition - -These eight criteria are grounded in three bodies of teaching held in common across the CDCF community. - -**Human dignity and genuine human control.** _Antiqua et Nova_ (Dicastery for the Doctrine of the Faith, January 2025) insists that AI must remain under genuine human moral -responsibility, distinguishes human intelligence from artificial statistical inference on anthropological and theological grounds, and establishes that "human dignity itself -depends on" maintaining real human control over AI-mediated decisions.[^1] Criteria 2 and 6 operationalize this requirement at the level of institutional deployment. - -**Subsidiarity and accountable authority.** Canon 627 of the Code of Canon Law requires that decisions be made at the appropriate level of authority with identifiable human -ownership.[^4] Canon 1609 establishes the pattern of collegiate deliberation, written conclusions, ordered discussion, and documented decision that grounds Criterion 6's governance -specification requirement.[^8] Criterion 8 extends subsidiarity from ecclesial governance into the deployment architecture of the tools themselves. - -**The common good over efficiency.** Pope Leo XIV, in his message to the Builders AI Forum (November 2025), called on AI builders to cultivate moral discernment as a profoundly -ecclesial endeavor and to develop systems that reflect justice, solidarity, and genuine reverence for life.[^2] This principle animates all eight criteria: Catholic institutions -are stewards, and stewardship requires that tools be evaluated against their effect on the full human person and the communities they serve, with cost savings and operational -throughput treated as secondary considerations. - ---- - -## Relationship to the Broader Governance Research - -These criteria represent the incubation and graduation layer of a broader governance architecture currently under discussion within U.S.A. C-DART 1 (Catholic Deep AI Research -Team), which is actively engaged in a structured planning process to evaluate and prioritize top AI trends facing Catholic institutions. Three research memos emerging from that -process inform the design of these criteria and are submitted alongside this document. - -**[Fragmented Catholic AI Governance at Scale](./fragmented-catholic-ai-governance.md)** documents why Catholic institutions across dioceses, health systems, and education networks -are producing dozens of incompatible governance standards for structurally identical use cases, and why a shared canonical baseline is urgent. This research provides the empirical -foundation for the criteria's design. - -**[Governance-as-Code for Catholic AI Agent Deployment](./governance-as-code-catholic-ai.md)** argues that deployment policies should become machine-readable, auditable -specifications operating as hard gates rather than advisory documents. This research informs Criterion 6's governance specification requirement and describes the more technically -rigorous implementation this framework is designed to grow into. - -**[Trusted Synthetic Data for Ministry-Scale AI](./trusted-synthetic-data-ministry-ai.md)** addresses the data infrastructure that would enable AI development across Catholic -health, education, social services, and parish life without exposing personal data. This research grounds Criterion 7's extended data stewardship requirements and anticipates the -data governance obligations accompanying more sophisticated Catholic AI development. - ---- - -## An Invitation to Iterate - -This is a v0.1 working draft. Every criterion is a proposal subject to revision through community input, pilot experience, and dialogue with ecclesial advisors. The goal is a -living standard that grows more precise and more useful as Catholic institutions begin applying it to real projects. - -Contributions, challenges, and proposed revisions are welcome via pull request or issue on the [CatholicOS GitHub](https://github.com/CatholicOS). - -_Drafted in dialogue with U.S.A. C-DART 1 (Catholic Deep AI Research Team). February–March 2026._ - ---- - -## Bibliography - -[^1]: - Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human - Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), - https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. - -[^2]: - Pope Leo XIV, "Message to Participants in the Builders AI Forum 2025," Vatican City, November 3, 2025, - https://www.vatican.va/content/leo-xiv/en/messages/pont-messages/2025/documents/20251103-messaggio-builders-aiforum.html. - -[^3]: - "The Real Lesson Behind the 'Father Justin' AI Priest Debacle," _America_, April 26, 2024, - https://www.americamagazine.org/faith/2024/04/26/father-justin-catholic-answers-ai-247808. - -[^4]: _Code of Canon Law_, Canon 627 (Vatican City: Libreria Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib2-cann460-572_en.html. - -[^5]: Commonwealth of Australia, _Royal Commission into the Robodebt Scheme: Final Report_ (Canberra: Commonwealth of Australia, 2023), https://robodebt.royalcommission.gov.au/. - -[^6]: - Julia Angwin, Jeff Larson, Surya Mattu, and Lauren Kirchner, "Machine Bias," _ProPublica_, May 23, 2016, - https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing. - -[^7]: - Pope Leo XIV, "Address to Participants in the Conference 'Artificial Intelligence and Care for Our Common Home,'" Vatican City, December 5, 2025, - https://www.vatican.va/content/leo-xiv/en/speeches/2025/december/documents/20251205-conferenza.html. - -[^8]: - _Code of Canon Law_, Canon 1609 (Vatican City: Libreria Editrice Vaticana, 1983), - https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html. - -[^9]: _Catechism of the Catholic Church_, 2nd ed., §1894 (Vatican City: Libreria Editrice Vaticana, 1997), https://www.vatican.va/archive/ENG0015/_INDEX.HTM. diff --git a/ai-governance/fragmented-catholic-ai-governance.md b/ai-governance/fragmented-catholic-ai-governance.md deleted file mode 100644 index d5d5d99..0000000 --- a/ai-governance/fragmented-catholic-ai-governance.md +++ /dev/null @@ -1,220 +0,0 @@ -# Fragmented Catholic AI Governance at Scale - -| | | -| :---------------- | :------------------------------------------------------------------------------------------ | -| **Document type** | Research memo | -| **Status** | Working draft — U.S.A. C-DART 1 discussion | -| **Relationship** | Supplementary research underlying [CDCF AI Vetting Criteria v0.1](./ai-vetting-criteria.md) | - ---- - -## Table of Contents - -1. [The Problem in One Sentence](#the-problem-in-one-sentence) -2. [Why Catholic Institutions Are Uniquely Exposed](#why-catholic-institutions-are-uniquely-exposed) -3. [What Fragmentation Looks Like in Practice](#what-fragmentation-looks-like-in-practice) -4. [Three Dioceses Building in Isolation](#three-dioceses-building-in-isolation) -5. [The Acceleration Curve](#the-acceleration-curve) -6. [Subsidiarity Without Solidarity](#subsidiarity-without-solidarity) -7. [What a Shared Canonical Standard Provides](#what-a-shared-canonical-standard-provides) -8. [Relationship to the CDCF Vetting Criteria](#relationship-to-the-cdcf-vetting-criteria) -9. [Bibliography](#bibliography) - ---- - -## The Problem in One Sentence - -Catholic institutions serving tens of millions of Americans across healthcare, education, and social services are deploying AI independently, producing governance regimes that are -incompatible with each other, cannot be jointly audited, and will be structurally difficult to unify once entrenched vendor relationships and diocesan contracts are in place. - ---- - -## Why Catholic Institutions Are Uniquely Exposed - -Catholic institutions occupy an unusual position in the American AI governance landscape. They are simultaneously subject to civil regulation, diocesan canonical authority, and the -moral theology of the Magisterium. No secular institution faces that combination. A hospital system deploying an AI triage tool must satisfy HIPAA, the FDA's Software as a Medical -Device framework, its diocesan bishop's authority over pastoral matters, and Catholic Social Teaching's account of human dignity and the common good, all in a single deployment -decision. - -The U.S. and China regulatory frameworks for AI are diverging in ways that compound this exposure. U.S. efforts emphasize system- and risk-based regulation, while Chinese rules -place relatively greater emphasis on content, security, and outputs.[^1] Catholic institutions operating internationally, and those receiving federal funding domestically, face -both frameworks without clarity on how to reconcile them with canonical requirements. - -The result is that Catholic institutions are caught between competing regulatory logics, without a shared canonical protocol that could provide coherent institutional guidance -across all three layers simultaneously. - ---- - -## What Fragmentation Looks Like in Practice - -The fragmentation is already producing concrete operational problems across the three primary institutional domains. - -| Domain | Scale | Fragmentation Impact | -| :------------------ | :----------------------------------------- | :-------------------------------------------------------------------------------------- | -| **Healthcare** | CommonSpirit: 24 states, multiple dioceses | Same tool, same patients, same mission — blocked or reconfigured at every diocesan line | -| **Education** | 5,905 Catholic schools nationally | Vendors face dozens of incompatible standards or default to generic secular products | -| **Social Services** | 168 Catholic Charities agencies | Cannot share tools, compare outcomes, or build on each other's governance work | - -**Healthcare.** CommonSpirit Health operates in 24 states across multiple dioceses.[^2] A single AI-assisted triage or clinical decision support tool cannot be deployed uniformly -across that system because each diocese it operates in carries different consent requirements, different pastoral boundary definitions, and different data governance expectations -developed independently. The same tool, the same patients, the same mission, reconfigured or legally blocked every time it crosses a diocesan line. - -**Education.** A vendor trying to serve all 5,905 Catholic schools in the United States[^3] faces dozens of incompatible responsible Catholic AI evaluation standards, each -developed by a different diocesan office operating without reference to the others. The vendor's options are to build bespoke configurations for every diocese, which is expensive -and unsustainable at scale, or to ignore Catholic-specific requirements entirely and deploy a generic secular product. The second outcome is precisely what Catholic AI governance -exists to prevent. - -**Social services.** The 168 Catholic Charities agencies operating across the country[^4] cannot share AI tools, cannot compare program outcomes across jurisdictions, and cannot -build on each other's governance work, because the regulatory and canonical regimes they operate under are incompatible. An AI intake screening tool that passes muster in one -diocese may be blocked in a neighboring one under criteria that were never designed to be interoperable. - ---- - -## Three Dioceses Building in Isolation - -Three U.S. dioceses built formal AI governance structures between 2024 and 2026. Each represents a serious, good-faith effort. None was built with reference to the others, and the -three models are structurally incompatible. - -| Diocese | Year | Governance Model | Instrument | -| :------------------- | :-------------------- | :---------------------------------------------- | :------------------------------- | -| Diocese of Orange | 2024 | Standing council with quarterly review | Living guidebook document | -| Diocese of Biloxi | Effective Jan 1, 2026 | Episcopal decree (binding canonical instrument) | Signed by Bishop Kihneman | -| Diocese of Arlington | June 2025 | Educator-led working group | School-specific policy framework | - -**Diocese of Orange (2024).**[^5] Established a standing Diocesan AI Council composed of the Vicar General, IT Director, HR, Communications, and parish pastors. The Council -maintains a living document guidebook and meets quarterly to review AI developments across diocesan operations, ministry, and education. - -**Diocese of Biloxi (effective January 1, 2026).**[^6] Issued an Episcopal Decree signed by Bishop Kihneman, a binding canonical instrument applying to all clergy, religious, lay -employees, and volunteers across the diocese. This appears to be the first formal episcopal AI decree in the United States. - -**Diocese of Arlington (June 2025).**[^7] Formed a 14-person working group of Catholic school educators who developed an AI policy framework distributed to Catholic schools across -the diocese, presented at a regional conference in August 2025. - -Three governance models with no shared evaluation standards, no common definition of what constitutes a permissible AI application, and no coordination mechanism. A vendor -evaluated favorably under Orange's council process has no assurance of meeting Biloxi's episcopal requirements or Arlington's school-specific framework. - ---- - -## The Acceleration Curve - -The fragmentation problem is active and accelerating. - -Commercial AI deployment in enterprise and institutional contexts moved from prototype to viral adoption in approximately 60 days in several documented cases in 2024 and 2025.[^8] -Catholic institutions are operating on a 12–18 month lag behind commercial deployment curves, which means the governance window is narrow and closing. - -Every month that passes without a shared canonical governance process, another diocese builds something incompatible. Vendors begin designing products to the fragmented landscape -rather than to a unified Catholic standard. Contracts get signed. Systems get deployed. Technical debt accumulates. What begins as a coordination gap becomes a structural feature -of Catholic AI governance that will require decades to unwind. - -The 3–6 month window for establishing shared baseline criteria before fragmentation becomes entrenched is the specific urgency that motivated the CDCF Vetting Criteria development. - ---- - -## Subsidiarity Without Solidarity - -The fragmentation is the predictable outcome of subsidiarity operating without a solidarity layer, produced by good-faith institutional actors working independently rather than by -governance failure. - -_Antiqua et Nova_ (§42) affirms that the responsibility for managing AI wisely "pertains to every level of society, guided by the principle of subsidiarity."[^9] Dioceses building -their own AI governance structures are doing exactly what subsidiarity asks them to do. The problem is that subsidiarity without a shared canonical foundation produces incompatible -local standards that cannot serve institutions like CommonSpirit or the Catholic Charities network, which operate across diocesan lines. - -Catholic Social Teaching is precise on this point. _Mensuram Bonam_ articulates that subsidiarity is considerably more than simple delegation, which often allows larger bodies to -retain power and ultimate control. Authentic subsidiarity "distributes roles and power horizontally, creating mutual accountability from all levels towards the common good."[^10] -Fragmented diocesan governance models are therefore not simply a failure of coordination; they represent a failure to execute the horizontal mutual accountability that subsidiarity -itself requires. The CDCF vetting standard is designed to fulfill that requirement: preserving local authority while establishing the mutual accountability that isolated local -action cannot provide. - -The Magisterium has provided rich doctrinal grounding for why human dignity, moral agency, and genuine human control over AI matter (_Antiqua et Nova_ is precise and substantial on -these points).[^9] Operational protocols that translate those principles into a shared canonical governance process remain to be developed. A diocese receiving a vendor proposal -for its schools or hospitals has principle-level guidance and no procedural framework for acting on it. - -The USCCB's joint letter on AI principles warns explicitly that automated decision-making systems used in employment screening, healthcare, public benefit screening, and related -domains "can reinforce existing biases or introduce a utilitarian approach devoid of necessary human considerations, with potentially devastating consequences."[^11] The letter -affirms the importance of ethical principles and reasonable policy, and it, too, stops short of a shared operational standard. - -The gap between principle and protocol is the specific problem this research addresses. Subsidiarity requires that local institutions govern themselves. Solidarity requires that -they do so within a framework coherent enough to serve the universal Church. A shared vetting standard preserves diocesan authority while providing the solidarity layer that makes -local authority coherent at scale. - ---- - -## What a Shared Canonical Standard Provides - -A shared vetting standard for Catholic AI tools resolves the fragmentation problem at the point where it is most tractable: the evaluation of tools before deployment. - -Rather than requiring every diocese to develop its own evaluation methodology from scratch, a shared standard provides a common baseline that any diocese can adopt, adapt for local -context, and apply consistently. Vendors evaluated against the shared standard have assurance of meeting Catholic institutional requirements across diocesan lines. Institutions -operating across multiple dioceses, including health systems, Catholic Charities networks, and school systems, can deploy tools under a single governance framework rather than -reconfiguring for every jurisdiction. - -The standard also functions as a market safeguard. Pope Leo XIV has demanded that AI governance ensure technology "truly serves the common good, and is not just used to accumulate -wealth and power in the hands of a few."[^12] A fragmented diocesan landscape is precisely the condition that allows vendors to exploit incompatible standards, accumulating data -and market position at the expense of local ministries. A shared canonical vetting standard closes that opening. - -_Antiqua et Nova_ further establishes that "greater autonomy heightens each person's responsibility across various aspects of communal life."[^9] Catholic institutions exercise -immense autonomy in American healthcare and education. That autonomy carries a correspondingly serious responsibility to demonstrate that their capacities are used in the service -of others. A shared vetting standard is the operational proof that Catholic institutions recognize and act on that responsibility. - -The standard preserves diocesan authority while providing the solidarity layer that allows subsidiarity to function coherently in an environment where AI tools routinely cross -institutional and jurisdictional boundaries. - ---- - -## Relationship to the CDCF Vetting Criteria - -The [CDCF AI Vetting Criteria](./ai-vetting-criteria.md) represent the first operational expression of this solidarity layer. The eight criteria, organized across two evaluation -gates, establish a shared baseline for what "vetted" means for AI tools submitted to the Catholic Digital Commons Foundation. - -The fragmentation research documented here provides the empirical foundation for why that baseline is urgent. The criteria are designed to be adoptable by any diocese, health -system, or Catholic institution regardless of which local governance model they operate under, whether standing council, episcopal decree, educator working group, or other. - ---- - -## Bibliography - -[^1]: - Oliver Guest and Kevin Wei, _Bridging the Artificial Intelligence Governance Gap: The United States' and China's Divergent Approaches to Governing General-Purpose Artificial - Intelligence_, Perspective PE-A3703-1 (Santa Monica, CA: RAND Corporation, December 2024), https://www.rand.org/pubs/perspectives/PEA3703-1.html. - -[^2]: - CommonSpirit Health, _Audited Consolidated Financial Statements as of and for the Years Ended June 30, 2024 and 2023_ (Chicago: CommonSpirit Health, 2024), - https://www.commonspirit.org/content/dam/shared/en/pdfs/investor-resources/2024-CommonSpirit-Health-Annual-Report.SECURED.pdf. - -[^3]: - National Catholic Educational Association, _United States Catholic Elementary and Secondary Schools 2023–2024: The Annual Statistical Report on Schools, Enrollment and - Staffing_ (Arlington, VA: NCEA, 2024), https://www.ncea.org/NCEA/NCEA/Who_We_Are/About_Catholic_Schools/Catholic_School_Data/Catholic_School_Data.aspx. - -[^4]: - Catholic Charities USA, _Pathways Forward: 2024 Annual Report_ (Alexandria, VA: Catholic Charities USA, 2025), - https://www.catholiccharitiesusa.org/publications/2024-annual-report/. - -[^5]: Diocese of Orange, "Diocesan AI Council," Roman Catholic Diocese of Orange, 2024, https://www.rcbo.org/ministry/artificial-intelligence-ai-council/. - -[^6]: Diocese of Biloxi, Episcopal Decree on Artificial Intelligence, signed by Bishop Louis F. Kihneman III, effective January 1, 2026, https://biloxidiocese.org/officials. - -[^7]: - "Catholic Schools Take Initiative in AI Challenge," _Catholic Herald_, June 2025, - https://www.catholicherald.com/article/local/catholic-schools-take-initiative-in-ai-challenge/. The policy framework referenced was developed by a 14-person educator working - group convened by the Diocese of Arlington and presented at a regional conference in August 2025. - -[^8]: - Ian Mitch, Matthew J. Malone, Karen Schwindt, Gregory Smith, Wesley Hurd, Henry Alexander Bradley, and James Gimbi, _Governance Approaches to Securing Frontier AI_, Research - Report RR-A4159-1 (Santa Monica, CA: RAND Corporation, 2025), https://www.rand.org/pubs/research_reports/RRA4159-1.html. - -[^9]: - Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human - Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), - https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. - -[^10]: - Pontifical Academy of Social Sciences, _Mensuram Bonam: Faith-Based Measures for Catholic Investors_ (Vatican City: Pontifical Academy of Social Sciences, 2022), - https://www.vatican.va/roman_curia/pontifical_academies/acdscien/documents/mensuram-bonam_en.html. - -[^11]: - United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, - https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. - -[^12]: - Pope Leo XIV, "Message to Participants in the Builders AI Forum 2025," Vatican City, November 3, 2025, - https://www.vatican.va/content/leo-xiv/en/messages/pont-messages/2025/documents/20251103-messaggio-builders-aiforum.html. diff --git a/ai-governance/governance-as-code-catholic-ai.md b/ai-governance/governance-as-code-catholic-ai.md deleted file mode 100644 index e90c0f9..0000000 --- a/ai-governance/governance-as-code-catholic-ai.md +++ /dev/null @@ -1,247 +0,0 @@ -# Governance-as-Code for Catholic AI Agent Deployment - -| | | -| :---------------- | :------------------------------------------------------------------------------------------ | -| **Document type** | Research memo | -| **Status** | Working draft — U.S.A. C-DART 1 discussion | -| **Relationship** | Supplementary research underlying [CDCF AI Vetting Criteria v0.1](./ai-vetting-criteria.md) | - ---- - -## Table of Contents - -1. [The Core Argument](#the-core-argument) -2. [What Governance-as-Code Is](#what-governance-as-code-is) -3. [Why Catholic Institutions Need It](#why-catholic-institutions-need-it) -4. [The Three-Layer Stack](#the-three-layer-stack) -5. [The Gate Decision as Primary Artifact](#the-gate-decision-as-primary-artifact) -6. [Honest Assessment of Institutional Readiness](#honest-assessment-of-institutional-readiness) -7. [What Catholic Institutions Can Do Now](#what-catholic-institutions-can-do-now) -8. [Relationship to the CDCF Vetting Criteria](#relationship-to-the-cdcf-vetting-criteria) -9. [Bibliography](#bibliography) - ---- - -## The Core Argument - -AI governance currently lives in PDFs and committee meetings. When a diocese, school, or Catholic hospital deploys an AI system, the governance process typically produces a -document that says the system is approved. That document exists separately from the system it governs. It cannot prevent a non-compliant deployment. It cannot be automatically -validated. It can only react after something goes wrong. - -Governance-as-code is the practice of turning those policy documents into machine-executable specifications wired directly into deployment pipelines. The governance becomes part of -the infrastructure. This shift is already occurring in regulated enterprise environments. The question for Catholic institutions is whether they participate in shaping what those -specifications encode, or whether they inherit secular governance schemas designed without reference to Catholic moral theology, canonical authority, or the Church's preferential -concern for the vulnerable. - ---- - -## What Governance-as-Code Is - -In a governance-as-code architecture, policy requirements are expressed as version-controlled schemas (typically JSON or YAML) that define exactly what an AI system must -demonstrate before it can reach production. When a developer attempts to deploy an agent, the deployment pipeline calls those schemas as hard gates. - -The gate logic is deterministic. Pass all gates and the agent deploys. Fail any gate and it does not. Every decision, pass or fail, is logged in an immutable audit trail that -regulators, diocesan authorities, or institutional leadership can examine after the fact. - -The schemas themselves define the governance criteria: what evidence of safety testing is required, what data domains the system is permitted to touch, what level of human -oversight it operates under, who the named accountable person is, and what conditions require escalation to a higher authority. These are the same questions the CDCF Vetting -Criteria ask. Governance-as-code is the technical architecture that makes those questions into enforceable gates rather than advisory checklists. - -This is distinct from using AI to govern AI. The gate decision in a governance-as-code architecture is deterministic: a schema either passes or it does not, based on explicit -criteria defined in advance by human authorities. AI can assist with evidence synthesis and risk surfacing within the pipeline, but the gate logic itself remains under -human-defined, machine-enforced control. This distinction matters because an AI-governed pipeline requires governance of its own, creating a regress that deterministic schema -enforcement avoids. - -Researchers studying multi-agent system failures have identified 14 distinct failure modes across three categories (system design issues, inter-agent misalignment, and task -verification breakdowns) underscoring the structural importance of deterministic gate logic rather than agent-mediated compliance review.[^1] Empirical survey data from 306 AI -practitioners across 26 domains confirms that reliability remains the top deployment challenge, with 68 percent of production agents executing ten or fewer steps before human -intervention is required.[^2] These findings argue for governance architectures in which human-defined, machine-enforced gates are the primary control mechanism rather than agent -judgment. - -A further structural concern is the compliance gap between regulatory intent and deployment practice. Current AI governance frameworks share three recurring gaps: scope ambiguity -in defining covered systems, point-in-time compliance requirements that fail to address systems that evolve after initial approval, and information asymmetries between regulators -and deploying institutions.[^3] - -| Framework | Jurisdiction | Key Gap | -| :------------------------- | :---------------- | :----------------------------------------------------- | -| California SB 53 | U.S. (California) | Scope ambiguity for covered systems | -| New York RAISE Act | U.S. (New York) | Point-in-time compliance, no post-approval tracking | -| U.S. AIREA | Federal | Information asymmetry between regulators and deployers | -| EU AI Act GPAI obligations | European Union | All three gaps present at scale | - -Governance-as-code directly addresses all three: schema definitions establish scope with precision, version-controlled schemas evolve with the system they govern, and immutable -audit trails close the information gap. - -The Commission of the Bishops' Conferences of the European Union (COMECE) affirms that evaluating AI from an ethical perspective "requires internal control principles and risk -assessment in addition to legislation."[^4] Governance-as-code is the direct instantiation of those mandated internal control principles, translating ethical evaluation from a -periodic review activity into a continuous, enforceable infrastructure requirement. - ---- - -## Why Catholic Institutions Need It - -The fragmentation problem documented in the companion memo on Catholic AI governance at scale is fundamentally a governance encoding problem. Each diocese is expressing its -Catholic AI values in a different format, at a different level of specificity, for different audiences. Orange wrote a council charter. Biloxi wrote a decree. Arlington wrote -school policy. None of those instruments are machine-readable. None of them can be automatically validated against. A vendor can acknowledge all three documents and deploy a -non-compliant system anyway, because the documents have no technical enforcement mechanism. - -Governance-as-code changes that structural relationship. A shared canonical governance schema, a baseline set of machine-executable policies encoding the principles of _Antiqua et -Nova_,[^5] the USCCB AI principles,[^6] and the Ethical and Religious Directives into version-controlled, reusable specifications, would let any diocese adopt the shared baseline -and extend it with local requirements. Subsidiarity is preserved because local authority still governs local decisions. Solidarity is achieved because every institution operating -on the shared baseline is interoperable. - -A vendor serving Catholic schools would face one canonical schema with optional diocesan extensions rather than dozens of incompatible checklists. A Catholic hospital system -operating across diocesan lines could deploy uniformly because the governance infrastructure is compatible across jurisdictions. The governance becomes as portable as the tools it -governs. - -The EU AI Act, with key obligations for high-risk AI systems taking effect in 2026, creates structural demand for auditable deployment governance in high-risk AI categories.[^7] -Catholic healthcare, education, and social services operate squarely in those categories. The regulatory pressure is arriving regardless of whether Catholic institutions have -prepared for it. - -The _Rome Call for AI Ethics_ demands that principles and values be instilled into a framework that "acts as a point of reference for digital ethics, guiding our actions and -promoting the use of technology to benefit humanity."[^8] The governance platform layer of this architecture directly answers that call, creating a shared, tangible reference point -for digital ethics that is enforceable across Catholic institutional boundaries rather than aspirational. - ---- - -## The Three-Layer Stack - -A mature governance-as-code architecture for Catholic AI deployment operates across three layers, each serving a distinct institutional function. - -| Layer | Function | Primary Users | CDCF Role | -| :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------- | :------------------------------------- | -| **Infrastructure** | CI/CD pipeline hooks, Kubernetes admission controllers, deployment gate logic. Where schemas execute as hard gates and audit trails are generated. | Developers and DevOps teams | Contributes schema specifications | -| **Governance Platform** | Schema library: version-controlled policy specifications, risk classification logic, canonical Catholic governance baseline. Where Catholic moral theology and canonical requirements are encoded as machine-readable criteria. | Diocesan IT offices and governance leads | Stewards the shared canonical baseline | -| **Application** | Institutional-facing tools: onboarding workflows, risk dashboards, audit artifacts for diocesan leadership and external regulators. | Parish and school administrators | Provides templates and tooling | - -These three layers correspond directly to the three levels of institutional capacity Catholic organizations actually have. A small parish or school operates primarily at the -application layer, using governance tools without needing to understand the infrastructure underneath. A diocesan IT office operates at the governance platform layer, adopting and -extending canonical schemas for local context. A large Catholic health system or university operates at the infrastructure layer, embedding governance gates into its own CI/CD -pipelines. - ---- - -## The Gate Decision as Primary Artifact - -The most significant design principle in this framework is that the gate decision itself, the go, conditional-go, no-go, or defer determination, is treated as a first-class -artifact rather than a byproduct of the review process. - -A gate decision artifact captures the specific evidence assembled, the confidence levels assigned, the gaps identified, the named human decision owner, the rationale for the -outcome, and the conditions under which the decision was made. It is immutable once recorded. It is the document that answers the regulator's question, the bishop's question, and -the affected person's question: why was this system deployed, under whose authority, and on what basis. - -This design directly reflects the canonical standard established in Canon 1609, which requires that deliberative processes produce written conclusions with reasons in law and in -fact, and that the capacity for review and appeal be preserved.[^9] A gate decision artifact is the technical implementation of that canonical requirement. - -The immutability of the audit trail also serves a specifically Catholic institutional concern. The USCCB warns that AI can be misused to "undermine the dignity of persons and -respect for the truth" through the manipulation of information.[^6] An immutable gate decision record ensures that if a deployed system begins generating falsehoods or utilitarian -biases, institutional accountability is clear, traceable, and preserved for review. The practical consequence of ungoverned audit trails is documented in enterprise deployments: -when a production AI system retrieves a superseded policy document with no captured provenance, the organization cannot reconstruct what the system saw or why, turning incident -response into forensic guesswork rather than evidence-based accountability.[^10] - -The four decision states carry distinct implications. - -| Decision State | Meaning | Documentation Requirement | -| :----------------- | :------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------- | -| **Go** | All governance criteria satisfied; deployment authorized | Full criteria evidence recorded | -| **Conditional-go** | Deployment authorized subject to specific conditions within a defined timeframe | Conditions and timeline specified; typically used when independent validation is pending | -| **No-go** | One or more criteria fell short; deployment blocked | Specific criteria and evidence gaps documented | -| **Defer** | Escalation to higher authority required before proceeding | Authority identified and reason specified | - ---- - -## Honest Assessment of Institutional Readiness - -Full technical implementation of governance-as-code at the infrastructure layer is beyond the current capacity of most Catholic institutions, and overstating that capacity would -produce the kind of governance credibility gap this framework is designed to prevent. Most Catholic institutions, including well-resourced dioceses and health systems, currently -operate at the application layer at best. They have policy documents. Some have review committees. Very few have version-controlled governance schemas. None, to the knowledge of -this research, have canonical Catholic governance schemas embedded as hard gates in CI/CD deployment pipelines. - -That gap is the opportunity, and it is the reason the CDCF Vetting Criteria are structured as they are. Criterion 6 requires a written, reviewable governance specification and -architectural compatibility with future enforcement. Full infrastructure-layer implementation is aspirational at the incubation stage. The governance specification written today -becomes the schema encoded tomorrow. The criteria are designed to build institutional capacity progressively, meeting institutions at their current maturity rather than requiring -capabilities still to be developed. - -A critique raised in C-DART 1 session discussions is worth acknowledging directly: healthcare governance in Catholic institutions is primarily a legal and regulatory problem rather -than an engineering problem. HIPAA, FDA, CMS, and state law set the floor. That critique is accurate, and this framework accepts it. Governance-as-code operates as the technical -layer that makes compliance with those frameworks auditable, reproducible, and interoperable across Catholic institutional boundaries. The distinction between replacing regulation -and making compliance technically enforceable is the distinction that makes this approach credible rather than overreaching. - ---- - -## What Catholic Institutions Can Do Now - -Given the honest assessment of current institutional readiness, the near-term contribution of this research is a written evaluation standard that functions as the precursor to a -production CI/CD governance pipeline rather than the pipeline itself. - -The CDCF Vetting Criteria represent that evaluation standard. Criterion 6 asks submitters to specify decision authority levels, escalation conditions, human review triggers, and -appeal processes in a written, reviewable document. That specification is the first step toward a machine-executable schema. An institution that has written a rigorous governance -specification for one tool has done most of the intellectual work required to encode that specification as a reusable governance schema. - -The CDCF is positioned to maintain the canonical schema library that individual institutions extend rather than build independently. That is the solidarity layer described in the -fragmentation memo: a shared baseline that preserves local authority while making Catholic AI governance interoperable at scale. - -Three concrete actions follow from this research for Catholic institutions at any level of technical maturity. - -1. **Require written governance specifications** for every AI tool under evaluation. The specification format in Criterion 6 of the CDCF Vetting Criteria provides a starting - template. -2. **Version-control those specifications.** Even a Word document in a shared drive with a version number and a named owner is a meaningful step toward governance-as-code - discipline. -3. **Evaluate vendor AI tools for schema compatibility:** does the tool's architecture support governance gate integration, or does it require overriding governance controls to - function? - ---- - -## Relationship to the CDCF Vetting Criteria - -Criterion 6 of the [CDCF AI Vetting Criteria](./ai-vetting-criteria.md) is the direct operational expression of this research. It requires a deployment governance specification as -a condition of incubation acceptance, with the four-state decision model (go, conditional-go, no-go, defer) as the structural framework for that specification. - -Criterion 8 extends the governance-as-code principle to the deployment architecture of the tools themselves, requiring that tools be deployable at the appropriate level of -ecclesial authority without overriding their core governance design. - -Together, Criteria 6 and 8 establish the governance specification requirements that position Catholic institutions to adopt fuller governance-as-code implementation as -institutional capacity develops. - ---- - -## Bibliography - -[^1]: - Mert Cemri, Melissa Z. Pan, Yapei Yang, Aditya Agrawal, Tatsunori Hashimoto, Diyi Yang, Qian Yang, and Percy Liang, "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657, - submitted March 17, 2025, https://arxiv.org/abs/2503.13657. - -[^2]: - Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou, and Percy Liang, "Measuring Agents in Production," arXiv:2512.04123, submitted December 2, 2025, revised - February 3, 2026, https://arxiv.org/abs/2512.04123. - -[^3]: - Joe Kwon and Stephen Casper, "Internal Deployment Gaps in AI Regulation," arXiv:2601.08005, submitted January 12, 2026, revised February 14, 2026, - https://arxiv.org/abs/2601.08005. - -[^4]: - Commission of the Bishops' Conferences of the European Union (COMECE), "Statement on the EU Artificial Intelligence Act," COMECE, 2024, - https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/. - -[^5]: - Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human - Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), - https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. - -[^6]: - United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, - https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. - -[^7]: - European Parliament and Council of the European Union, _Regulation (EU) 2024/1689 of the European Parliament and of the Council Laying Down Harmonised Rules on Artificial - Intelligence (Artificial Intelligence Act)_, Official Journal of the European Union, August 12, 2024, https://artificialintelligenceact.eu. - -[^8]: - Pope Francis, "Address at the Signing of the Rome Call for AI Ethics," Vatican City, February 28, 2020, - https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html. - -[^9]: - _Code of Canon Law_, Canon 1609 (Vatican City: Libreria Editrice Vaticana, 1983), - https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html. - -[^10]: Rick Hamilton, "Data Governance for AI Must Be Executable," _hamiltonandboss.com_ (Substack), 2025, https://substack.com/@rickwritesai/p-189861656. diff --git a/ai-governance/trusted-synthetic-data-ministry-ai.md b/ai-governance/trusted-synthetic-data-ministry-ai.md deleted file mode 100644 index 4ae2a90..0000000 --- a/ai-governance/trusted-synthetic-data-ministry-ai.md +++ /dev/null @@ -1,243 +0,0 @@ -# Trusted Synthetic Data for Ministry-Scale AI - -| | | -| :---------------- | :------------------------------------------------------------------------------------------ | -| **Document type** | Research memo | -| **Status** | Working draft — U.S.A. C-DART 1 discussion | -| **Relationship** | Supplementary research underlying [CDCF AI Vetting Criteria v0.1](./ai-vetting-criteria.md) | - ---- - -## Table of Contents - -1. [The Core Argument](#the-core-argument) -2. [What Synthetic Data Is](#what-synthetic-data-is) -3. [The Market Signal](#the-market-signal) -4. [The Catholic Data Paradox](#the-catholic-data-paradox) -5. [What Catholic Institutions Could Build](#what-catholic-institutions-could-build) -6. [The Three-Layer Stack](#the-three-layer-stack) -7. [The Federated Architecture Imperative](#the-federated-architecture-imperative) -8. [The CDCF Role: Validation Standards, Not Data Commons](#the-cdcf-role-validation-standards-not-data-commons) -9. [Relationship to the CDCF Vetting Criteria](#relationship-to-the-cdcf-vetting-criteria) -10. [Bibliography](#bibliography) - ---- - -## The Core Argument - -Catholic institutions collectively hold one of the largest concentrations of sensitive data stewardship in America. They serve the same overlapping populations across healthcare, -education, social services, and parish life in a way no secular institution can replicate. That cross-domain view is also completely inaccessible for AI development because the -data is protected by HIPAA, FERPA, diocesan privacy norms, and the pastoral trust of the people it concerns. - -Trusted synthetic data resolves that tension. AI systems can now generate statistically faithful but entirely artificial versions of sensitive datasets, preserving the -population-level patterns that make data valuable for model training while eliminating the individual-level records that make it legally and ethically off-limits. This technology -crossed the production threshold in 2025. The question for Catholic institutions is whether they develop the governance infrastructure to use it on their own terms, or whether -their unique cross-domain data position remains permanently unavailable for the AI development that could serve their missions most effectively. - ---- - -## What Synthetic Data Is - -Synthetic data is algorithmically generated data that mirrors the statistical properties, distributions, and relationships of a real dataset without containing any actual records -from real individuals. A synthetic patient cohort drawn from a hospital system's electronic health records preserves the clinical patterns, demographic distributions, comorbidity -relationships, and outcome rates of the real population while containing zero real patients. No individual record can be traced back to a real person because no individual record -from a real person was used to generate it. - -The distinction between synthetic data and anonymized data is consequential. Anonymized datasets remove or mask identifying fields, but the underlying records still correspond to -real individuals, and re-identification attacks have demonstrated that anonymization alone provides insufficient protection for sensitive populations. Synthetic data generates new -records from learned distributions. Re-identification risk is dramatically reduced when datasets are fully synthetic, because synthetic records carry no real-world counterparts, -but privacy still requires careful design and independent testing before the data can be trusted for consequential use. - -Quality validation is the critical governance requirement. A synthetic dataset is valuable for AI training only if it accurately preserves the statistical properties of the source -data. Validation frameworks measure fidelity (the degree to which synthetic distributions match real distributions) and privacy, the degree to which synthetic records resist -membership inference attacks. Both dimensions require rigorous, independent validation before synthetic data can be trusted for consequential AI development. - ---- - -## The Market Signal - -Two market signals establish that synthetic data has crossed from experimental to production-grade infrastructure. - -| Signal | Organization | Year | Significance | -| :---------------------------- | :----------------------------- | :----------- | :---------------------------------------------------------------------------------------------------------------------------- | -| NVIDIA acquires Gretel | NVIDIA / Gretel | 2025 | $320M+ acquisition positions synthetic data generation as foundational enterprise AI infrastructure, not a niche privacy tool | -| VA deploys MDClone nationally | Veterans Health Administration | 2020–present | Demonstrates production-scale synthetic health data under federal regulatory oversight | - -NVIDIA acquired Gretel, the leading synthetic data generation platform, for more than $320 million in 2025.[^1] NVIDIA's acquisition thesis was explicit: synthetic data is -essential infrastructure for AI development in regulated industries where real data is legally inaccessible or practically unavailable at the scale AI training requires. The -acquisition positioned synthetic data generation as a foundational capability within NVIDIA's enterprise AI stack rather than a niche privacy tool. - -The U.S. Department of Veterans Affairs, through the Veterans Health Administration, has deployed MDClone as a synthetic data engine to support multiple clinical and research use -cases.[^2] The VHA deployment demonstrated that synthetic data generation can operate at national health system scale under federal regulatory oversight, with validated fidelity -sufficient to support clinical AI development and outcomes research. - -These signals matter for Catholic institutions because they establish that the technology is production-ready and that the regulatory and governance questions, while real, are -solvable. The VA deployment answers the question of whether synthetic health data can meet federal data governance requirements. The NVIDIA acquisition signals that major -enterprise AI infrastructure investment is flowing into this capability. - ---- - -## The Catholic Data Paradox - -Catholic institutions face an acute version of the AI-data paradox: they hold exactly the data AI needs, and they hold it in a configuration no secular institution can replicate. - -| Domain | Scale | Data Type | Legal Protection | -| :----------------------------- | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------- | :------------------------------------- | -| **Healthcare** | 650 hospitals · 2,200+ facilities · 1 in 7 U.S. patients · 19M emergency visits/year | EHR, clinical outcomes, demographic data | HIPAA | -| **Education** | 5,905 schools · 1.68M students · 150,000+ staff | Academic performance, behavioral, family, sacramental records | FERPA | -| **Social Services & Parishes** | 168 agencies · 28M meals · 295,000 emergency housing placements | Immigration, counseling, housing, case management, parish engagement | Diocesan privacy norms, pastoral trust | - -**Catholic healthcare** is the largest group of nonprofit healthcare providers in the United States: 650 hospitals and more than 2,200 total facilities caring for one in seven -American patients daily, with approximately 19 million emergency visits and 5.6 million hospital admissions annually.[^3] The three largest Catholic health systems (CommonSpirit -Health, Ascension, and Trinity Health) collectively operate more than 370 hospitals with combined revenues exceeding $90 billion.[^3] [^4] This data is protected by HIPAA and is -largely inaccessible for cross-institutional AI development without extended IRB processes and data sharing agreements that rarely scale. - -**Catholic education** enrolls 1.68 million students across 5,905 schools with more than 150,000 professional staff.[^5] These FERPA-protected records include academic performance, -behavioral data, family information, and, uniquely, sacramental records. The accelerating trend toward diocesan centralized management, which has grown from 2.4 percent of -elementary schools in 1990 to 18 percent in 2023, creates both opportunity and risk: centralization enables system-wide analytics but concentrates sensitive data in ways that -amplify governance obligations.[^5] - -**Catholic social services and parishes** encompass 168 Catholic Charities agencies that served more than 28 million meals and provided emergency housing to 295,000 people in 2024, -while responding to 52 disasters.[^6] Their data includes immigration records, counseling records, housing data, and case management information for some of America's most -vulnerable populations. Thousands of parishes hold additional data on the same families across giving patterns, sacramental participation, and community engagement. - -The cross-domain overlap is the distinctive asset. A family that receives care at a Catholic hospital, educates their children at a Catholic school, receives services from Catholic -Charities, and participates in parish life appears in four separate Catholic data systems. No secular institution has that cross-domain view of the same overlapping populations. -That view is precisely what makes Catholic data potentially valuable for AI development, and precisely what makes its governance obligations most serious. - ---- - -## What Catholic Institutions Could Build - -Synthetic versions of Catholic institutional data would unlock AI development that is currently structurally impossible. - -| Use Case | Data Source | AI Applications Unlocked | -| :------------------------ | :------------------------------------------------ | :---------------------------------------------------------------------------------- | -| **Healthcare** | Synthetic EHR cohorts across 650 hospitals | Diagnostic AI, clinical operations, multi-system population research | -| **Education** | Synthetic student records across 5,905 schools | Early-warning systems, retention models, system-wide benchmarking | -| **Social Services** | Synthetic case data across 168 Charities agencies | Program effectiveness, homelessness prediction, neighborhood vulnerability modeling | -| **Research Partnerships** | Cross-institutional synthetic cohorts | NIH studies, public health research, minority population outcomes | - -**Healthcare.** Synthetic EHR cohorts across 650 hospitals would enable diagnostic AI development, clinical operations optimization, and multi-system research on population -patterns without triggering PHI sharing workflows or extended IRB delays.[^3] Catholic hospitals disproportionately serve underrepresented and underserved populations that -commercial AI training datasets consistently underrepresent. A synthetic Catholic health data commons would enable AI models trained on populations that actually reflect the -communities Catholic healthcare serves. - -**Education.** Synthetic student records across 5,905 schools would allow diocesan education offices to build early-warning systems for at-risk students, retention models, and -system-wide performance benchmarking without real student data ever leaving its source system.[^5] The sacramental and pastoral context within Catholic school data creates -dimensions of student and family life that no secular education dataset captures. - -**Social services.** Synthetic case management data across 168 Catholic Charities agencies would enable program effectiveness analysis, cross-agency learning, and -neighborhood-level modeling of vulnerability and need, including predictive models for homelessness, food insecurity, and family crisis, without exposing individual client -identities.[^6] The combination of social services data with parish community data creates a neighborhood-level picture of human need that has no secular equivalent. This use case -is a direct technical execution of the Church's Preferential Option for the Poor: AI systems built on this infrastructure would see and serve the marginalized without exploiting -their data, ensuring that the most vulnerable populations benefit from AI development rather than being rendered invisible by datasets that consistently underrepresent them. - -**Research partnerships.** Academic medical centers and public health researchers face chronic data access constraints for studies on underserved and minority populations. Catholic -health systems serve those populations at scale. A governed synthetic data infrastructure would position Catholic institutions as research partners for NIH-funded studies, public -health initiatives, and academic collaborations, generating both research impact and institutional revenue without exposing real patient data. - -A governance obligation follows from each of these use cases. The USCCB's AI principles are direct: automated decision-making systems used in healthcare, education, and social -services can reinforce existing biases or introduce a utilitarian approach that displaces necessary human considerations.[^7] The USCCB further teaches that technology should -"supplement what human beings do, not replace them or their moral judgments."[^7] Models trained on Catholic synthetic data must be designed to supplement the judgment of doctors, -teachers, and social workers, and the CDCF certification criteria for applications using synthetic data should require that human professionals retain ultimate decision-making -authority. - -U.S. Catholic institutions also serve large populations of Latin American descent, particularly in healthcare and social services. The Latin American and Caribbean Episcopal -Council has called for AI applications to be critically evaluated in particular local contexts to determine whether they advance human dignity and the common good in practice.[^8] -The federated synthetic data framework provides exactly the mechanism needed to safely develop and evaluate AI serving these specific demographic communities, ensuring that -context-specific needs shape the models rather than being obscured by them. - ---- - -## The Three-Layer Stack - -A Catholic synthetic data infrastructure operates across three layers that correspond to the same institutional capacity levels described in the governance-as-code memo. - -| Layer | Function | Primary Users | CDCF Role | -| :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------- | :------------------------------------------------------- | -| **Infrastructure** | Production synthetic data generators (NeMo, MDClone, SAS) with PHI/PII-sensitive pipeline controls. Handles technical generation and fidelity validation. | Large health systems and university research centers | Contributes validation specifications | -| **Governance Platform** | Catholic-specific governance framework encoding quality validation standards, ERD alignment, USCCB compliance, and access-control patterns as reusable policy. | Diocesan governance offices and data stewards | Stewards validation standards and certification criteria | -| **Application** | Ready-made tools running on synthetic datasets: diocesan education dashboards, Charities program evaluation tools, parish community health models. | Diocesan offices, parishes, small agencies | Provides certified application templates | - ---- - -## The Federated Architecture Imperative - -A critique raised in C-DART 1 session discussions warrants direct acknowledgment: data heterogeneity across legally independent Catholic institutions would make a pooled Catholic -data commons technically unsound. Catholic hospitals, schools, and Charities agencies operate under different legal entities, different regulatory frameworks, and different -diocesan governance structures. Their data schemas, data quality, and data governance norms are incompatible in ways that would produce noise rather than signal if combined -naively. - -That critique is accurate, and it has a specific architectural response: federated synthetic data generation rather than pooled data commons. - -In a federated architecture, synthetic data generation occurs locally at each institution using its own source data. The generated synthetic datasets, rather than the real data, -are what move between institutions or become available for research and AI development. Each institution retains full control over its source data. The CDCF's role in this -architecture is to establish the validation standards and certification criteria that ensure synthetic datasets generated at different institutions are interoperable and -trustworthy, without requiring those institutions to share or pool their underlying real data. - -This reframes the CDCF's contribution from data infrastructure operator (a role that would require legal authority, technical capacity, and governance structures the Foundation -currently lacks) to standard-setter and validator, a role that aligns precisely with what the CDCF is designed to do. - ---- - -## The CDCF Role: Validation Standards, Not Data Commons - -The CDCF is positioned to make three specific contributions to Catholic synthetic data infrastructure that require governance expertise rather than data operations. - -| Contribution | What It Defines | Why It Matters | -| :-------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------ | -| **Validation standards** | Fidelity and privacy thresholds a synthetic dataset must meet for Catholic institutional certification — statistical distance, privacy attack resistance, domain-specific criteria for health, education, and social services | Shared standards prevent each institution from solving the same problem independently | -| **Certification criteria** | What a synthetic data generation process must demonstrate to receive CDCF certification, paralleling the AI vetting criteria | Gives Catholic institutions assurance that certified platforms produce trustworthy synthetic data | -| **Interoperability requirements** | Data standards and schema conventions allowing synthetic datasets from different Catholic institutions to be combined or compared for multi-institutional research | Technical complement to governance interoperability the vetting criteria provide for AI tools | - ---- - -## Relationship to the CDCF Vetting Criteria - -Criterion 7 of the [CDCF AI Vetting Criteria](./ai-vetting-criteria.md) addresses training data governance directly: a tool trained on data from Catholic institutions carries an -obligation to those institutions and to the populations they serve, and the terms under which that data was used must be disclosed and evaluated as part of the graduation review. - -That criterion anticipates a future in which Catholic institutions are actively developing AI tools trained on Catholic institutional data. Trusted synthetic data infrastructure is -what makes that future possible at scale. An institution that deploys validated synthetic data generation can develop AI tools for its own use and contribute to shared Catholic AI -development without the legal exposure and governance burden that use of real institutional data would require. - -The three research memos (fragmentation, governance-as-code, and trusted synthetic data) form an integrated argument. Fragmentation establishes why shared governance standards are -urgent. Governance-as-code provides the deployment enforcement architecture. Trusted synthetic data provides the data infrastructure that allows Catholic institutions to develop AI -worthy of that governance architecture. - ---- - -## Bibliography - -[^1]: - Paresh Dave, "Nvidia Reportedly Acquires Synthetic Data Startup Gretel," _TechCrunch_, March 19, 2025, - https://techcrunch.com/2025/03/19/nvidia-reportedly-acquires-synthetic-data-startup-gretel/. NVIDIA declined official comment; no corporate press release has been issued. - -[^2]: - U.S. Department of Veterans Affairs, Veterans Health Administration, "Synthetic Data to Improve Veteran Care," VA News, December 2020, - https://news.va.gov/81908/synthetic-data-improve-veteran-care/. - -[^3]: - Catholic Health Association of the United States, _Catholic Health Care in the United States_ (Washington, DC: Catholic Health Association, 2024), - https://www.chausa.org/about/facts---statistics. - -[^4]: - CommonSpirit Health, _Audited Consolidated Financial Statements as of and for the Years Ended June 30, 2024 and 2023_ (Chicago: CommonSpirit Health, 2024), - https://www.commonspirit.org/content/dam/shared/en/pdfs/investor-resources/2024-CommonSpirit-Health-Annual-Report.SECURED.pdf. - -[^5]: - National Catholic Educational Association, _United States Catholic Elementary and Secondary Schools 2023–2024: The Annual Statistical Report on Schools, Enrollment and - Staffing_ (Arlington, VA: NCEA, 2024), https://www.ncea.org/NCEA/NCEA/Who_We_Are/About_Catholic_Schools/Catholic_School_Data/Catholic_School_Data.aspx. - -[^6]: - Catholic Charities USA, _Pathways Forward: 2024 Annual Report_ (Alexandria, VA: Catholic Charities USA, 2025), - https://www.catholiccharitiesusa.org/publications/2024-annual-report/. - -[^7]: - United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, - https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. - -[^8]: - Latin American and Caribbean Episcopal Council (CELAM), _Inteligencia Artificial: Una mirada pastoral desde América Latina y el Caribe_ (Bogotá: CELAM, May 2025), - https://adn.celam.org/celam-presenta-documento-inedito-sobre-inteligencia-artificial-una-mirada-pastoral-desde-america-latina-y-el-caribe/. diff --git a/project-governance/project-vetting-criteria.md b/project-governance/project-vetting-criteria.md index 3708dc4..692a965 100644 --- a/project-governance/project-vetting-criteria.md +++ b/project-governance/project-vetting-criteria.md @@ -1,10 +1,10 @@ -# CDCF Project Vetting Criteria: General Framework +# CDCF Project Vetting Criteria -| | | -| :--------------- | :---------------------------------------------------------------------------------------------- | -| **Version** | v0.1 (draft for community review) | -| **Scope** | All technology projects submitted for CDCF incubation and graduation | -| **Relationship** | This is the generalized framework. Specialized domains (e.g., AI) may have additional criteria. | +| | | +| :--------------- | :------------------------------------------------------------------------------------------------------------------------------- | +| **Version** | v0.2 (draft for community review) | +| **Scope** | All technology projects submitted for CDCF incubation and graduation | +| **Note** | Domain-specific extensions (beginning with AI) are integrated inline. Additional domains may be added as the Foundation evolves. | --- @@ -22,6 +22,9 @@ - [Criterion 7: Documentation for Independent Deployment and Data Stewardship](#criterion-7-documentation-for-independent-deployment-and-data-stewardship) - [Criterion 8: Governance, Maintenance, and Subsidiarity Compatibility](#criterion-8-governance-maintenance-and-subsidiarity-compatibility) 4. [Grounding in Catholic Teaching and Canonical Tradition](#grounding-in-catholic-teaching-and-canonical-tradition) +5. [Relationship to the Broader Governance Research](#relationship-to-the-broader-governance-research) +6. [An Invitation to Iterate](#an-invitation-to-iterate) +7. [Bibliography](#bibliography) --- @@ -31,67 +34,315 @@ The Catholic Digital Commons Foundation (CDCF) serves the Church by fostering a Without shared standards, Catholic institutions risk technical and canonical fragmentation, deploying tools that may not align with our mission or that operate without clear lines of accountability. -This document establishes the general requirements for any project seeking CDCF endorsement. It follows a two-gate structure: **Gate 1** for incubation acceptance and **Gate 2** -for graduation to active project status. +Catholic institutions serve tens of millions of people across healthcare, education, social services, and parish life. They are actively evaluating and deploying technology to do +this work more effectively, and in many domains — AI most prominently among them — they are doing so without a shared, canonical standard for what responsible Catholic deployment +looks like. The consequence is fragmentation: dioceses, school systems, and Catholic Charities agencies operating under incompatible evaluation criteria for structurally identical +use cases, with tools that touch sensitive populations entering production without a documented discernment process. -| Gate | Stage | Requirement | -| :--------- | :-------------------------- | :----------------------------------------------------------------------------- | -| **Gate 1** | Incubation Acceptance | Criteria 1 through 6 must be satisfied. | -| **Gate 2** | Graduation to Active Status | Criteria 7 and 8 must be satisfied, and Gate 1 criteria must remain satisfied. | +This document establishes the requirements for any project seeking CDCF endorsement. Its foundational premise is practical and specific: **the humans inside a system determine +whether the governance holds.** Policies, principles, and frameworks carry weight only when they are traceable to named individuals with real authority and real accountability. In +Catholic institutional life, that premise has deep roots. The Church teaches that human intelligence is an essential aspect of being created in the image of God, and that +technological innovation represents a participation in the divine act of creation.[^1] Because every design choice "expresses a vision of humanity," developers carry an obligation +to build systems that "reflect justice, solidarity, and a genuine reverence for life."[^2] These criteria translate that obligation into an operational standard that developers, +dioceses, and ecclesial advisors can apply consistently. + +The criteria are organized around two evaluation gates. **Gate 1** governs acceptance into incubation. **Gate 2** governs graduation to active CDCF project status. A project +advances through Gate 2 only after satisfying Gate 1 in full. + +| Gate | Stage | Criteria | Requirement | +| :--------- | :-------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------ | +| **Gate 1** | Incubation Acceptance | C1 Mission Alignment · C2 Human Accountability · C3 Transparency · C4 Independent Validation · C5 Vulnerable Population Impact · C6 Deployment Governance | All six required | +| **Gate 2** | Graduation to Active Status | C7 Documentation and Data Stewardship · C8 Governance and Subsidiarity | Both required; Gate 1 must remain satisfied | --- ## Gate 1: Incubation Acceptance +> All six criteria are required for incubation acceptance. A project satisfying five of six criteria remains in pre-submission dialogue until the sixth is resolved. + +--- + ### Criterion 1: Mission Alignment and Canonical Scope -The project must serve a purpose coherent with the Church's evangelizing mission and with Catholic Social Teaching. It must be respectful of human dignity, conducive to human -flourishing, and of potential service to the Church at a wide level. +The project must serve a purpose coherent with the Church's evangelizing mission and with Catholic Social Teaching's account of human dignity, the common good, and subsidiarity. +Projects with the potential to serve any parish, diocese, school, or ministry facing a structurally similar need take priority over projects designed for a single institution's +bespoke requirements. **Canonical boundaries.** Technology projects must not attempt to simulate sacramental functions or present themselves as having ecclesial authority they do not possess. +**AI domain extension.** Certain AI applications fall outside the scope of CDCF endorsement regardless of technical quality. The doctrinal basis for these boundaries is precise. +The Church distinguishes human intelligence (understood as a synthesis of _intellectus_ (the intuitive grasp of truth) and _ratio_ (discursive reasoning) belonging to a person +composed of body and soul) from artificial statistical inference, which processes data without the capacity to think in any theologically meaningful sense.[^1] Because human beings +are ordered by their nature to interpersonal communion, and because the sacraments are incarnational realities rooted in the unity of body and soul, AI systems are constitutively +incapable of mediating sacramental grace or spiritual direction. + +The following AI applications are disqualifying: + +- Tools that simulate sacramental functions, including confession, absolution, or spiritual direction +- Tools that present AI-generated content as authoritative Church teaching without explicit human theological review +- Tools that assign a clerical identity, title, or visual presentation suggesting ordained status to an AI system + +These boundaries derive from documented failures in Catholic AI deployment. In April 2024, Catholic Answers launched "Father Justin," an AI chatbot presented as a priest-figure. +The system required rapid withdrawal within the first days of launch after it presented itself as a priest and claimed it could administer sacraments.[^3] A shared boundary +condition defined in advance would have identified this application as out of scope before a single line of code shipped. + +**Evaluation question:** Could this project serve the universal Church, or does its value proposition depend on institutional specificity that constrains its broader applicability? + +--- + ### Criterion 2: Human Accountability Architecture -Every consequential action or decision informed by the project must be attributable to a named, accountable human being. Accountability must be traceable to specific individuals -operating within defined systems of consultation, in accordance with the principles of Catholic governance (cf. Canon 627). +Every consequential action or decision informed by the project must be attributable to a named, accountable human being, a specific person identified by role and institutional +position, who carries responsibility for that output and who can be held to account by the persons affected. Accountability distributed across a committee without a named decision +owner falls short of this criterion. + +The doctrinal grounding is unambiguous. Decision-making about the lives of persons "must always be left to the human person."[^1] As Pope Francis stated directly: "We would +condemn humanity to a future without hope if we took away people's ability to make decisions about themselves and their lives, by dooming them to depend on the choices of machines." +Maintaining proper human control over technology-mediated decisions is a binding moral requirement; "human dignity itself depends on it."[^1] + +This requirement also operationalizes Canon 627 of the Code of Canon Law, which establishes that superiors must use councils with defined consent and counsel obligations, and that +consequential authority is always tied to specific individuals operating within defined systems of consultation.[^4] In Catholic governance, authority is never an autonomous or +untraceable mechanism. + +The structural failure documented in the Australian Robodebt scheme (2016–2019) illustrates what the removal of named human accountability produces at scale: hundreds of thousands +of unlawful debt notices and multiple deaths among vulnerable welfare recipients, attributed by the Royal Commission directly to the absence of human review from consequential +decisions about individuals.[^5] + +**Evaluation questions:** + +- Can a person affected by this project's output identify who made the decision and through what process? +- Does the project's design make human override clear, documented, and reversible? + +--- ### Criterion 3: Transparency of Scope and Operation -The project must provide accurate documentation of its operation, its dependencies, its data usage, and its intended impact. This documentation must be sufficient for independent -technical and canonical review. +The submitter must provide technically accurate documentation of what the project does, what data it ingests, who is affected by its outputs, what decisions it informs or makes, +and where its operational boundaries lie. This documentation must be sufficient for an independent technical reviewer to assess the project's actual behavior without relying on +vendor marketing materials. + +The Magisterium is explicit that the "inherent dignity of each human being and the fraternity that binds us together" must serve as the "indisputable criteria for evaluating new +technologies before they are employed."[^1] Evaluation requires information. A project whose operation cannot be independently described cannot be evaluated against those criteria. + +**AI domain extension.** For AI tools that involve automated or algorithmically-assisted decision-making about people, including hiring, resource allocation, triage, content +recommendation, and risk assessment, this criterion additionally requires: + +- Disclosure of training data sources and known distributional limitations +- Documentation of any independent audits or evaluations conducted +- Clear description of which decisions the tool makes autonomously and which require human review + +The absence of this documentation signals that the submitter has work remaining before an informed deployment decision is possible. CDCF endorsement of an undocumented tool would +expose Catholic institutions to the same opacity risks that produced systemic bias in the COMPAS criminal sentencing algorithm, where risk scores were found to be nearly twice as +likely to falsely flag Black defendants as high risk compared to white defendants, before institutional accountability mechanisms were engaged.[^6] + +--- ### Criterion 4: Independent Validation of Claimed Capabilities -The submitter must provide evidence that the project's claimed capabilities have been validated by sources independent of the primary developers (e.g., third-party audits, peer -reviews, or documented benchmarking). +The submitter must provide evidence that the project's claimed capabilities have been evaluated against sources independent of the vendor or developer. Vendor documentation, +marketing materials, and internal testing reports are inputs to this review; independent validation stands apart from them. + +Acceptable forms of independent validation include: + +| Validation Type | Description | +| ------------------------------ | ----------------------------------------------------- | +| Third-party technical audit | External assessment of system behavior and claims | +| Peer-reviewed evaluation | Published academic or professional review | +| Published benchmarking | Results from recognized evaluation frameworks | +| Documented red-team assessment | Structured adversarial testing with recorded findings | + +Where such validation is pending, the submitter must disclose that explicitly and provide a concrete plan and timeline for obtaining it. A project in active pursuit of independent +validation may be accepted into incubation with this criterion marked as a condition of graduation rather than a barrier to entry. + +The standard applied here is proportionate to stakes. A project that assists with internal scheduling carries different validation requirements than one that informs hiring +decisions, student placement, or access to social services. The CDCF review process applies judgment accordingly. + +--- ### Criterion 5: Impact on Vulnerable Populations The project must demonstrate that its impact has been examined with particular attention to the "preferential option for the poor" and those most vulnerable to technological exclusion or harm. +Catholic institutions disproportionately serve populations that commercial technology development pipelines have historically underrepresented: + +- The elderly and people with disabilities +- Recent immigrants and non-English-speaking communities +- Communities in poverty and populations in rural or underserved areas + +Deploying tools without examining their impact on these populations is inconsistent with the Church's preferential option for the poor and vulnerable, and it is a governance +failure regardless of aggregate performance metrics. + +Pope Leo XIV identifies the risk precisely: technology development becomes a moral failure when it produces systems that allow human beings to become "merely passive consumers of +content generated by artificial technology," eroding the capacity to "reflect, choose freely, love unconditionally and enter into authentic relationships."[^7] Tools that +systematically degrade outcomes for vulnerable populations accelerate exactly that erosion for the people with the least capacity to resist it. + +**AI domain extension.** For AI tools, this criterion requires a documented subgroup performance analysis: evidence that the tool's accuracy, error rates, and outcomes have been +examined across the specific populations it will affect, with particular attention to groups underrepresented in typical training datasets or carrying heightened vulnerability to +algorithmic harm. The Magisterium defines algorithmic bias as "systematic and consistent errors in computer systems that may disproportionately prejudice certain groups in +unintended ways."[^1] + +This criterion requires either documented subgroup performance analysis or an explicit acknowledgment of its absence paired with a concrete plan to obtain it. A submitter who has +engaged these questions with rigor and documented both the evidence and the gaps satisfies this criterion. + +--- + ### Criterion 6: Deployment Governance Specification -The submitter must specify the governance conditions under which the project will operate, including decision authority levels, escalation conditions, and appeal processes for -those affected by the project's outputs. +The submitter must specify the governance conditions under which the project will operate. This criterion addresses the consequential gap between a project that is technically +sound in isolation and one that is responsibly deployed in an institutional context. + +**Required elements:** + +| Element | Description | +| ------------------------ | ------------------------------------------------------------------------- | +| Decision authority level | Parish, diocese, institution, or board; clearly mapped | +| Escalation conditions | Defined triggers requiring higher authority involvement | +| Human review triggers | Thresholds at which outputs require human examination before action | +| Appeal process | Process by which affected persons can contest a project-influenced decision | + +The canonical grounding for these requirements is specific. Canon 1609 dictates that judges in a collegiate tribunal must submit written conclusions with reasons in law and in +fact, followed by structured discussion. Judges retain the right to withdraw from an original conclusion and to demand that dissent be transmitted to a higher tribunal.[^8] This +canonical standard establishes that Catholic decision-making requires conscious reasoning, the capacity to revise judgments, and transparent mechanisms for appeal; a deployment +governance specification must preserve these capacities in human hands. + +This criterion draws on the governance-as-code design pattern, in which deployment policies are expressed as machine-readable, auditable specifications rather than policy documents +that exist separately from the systems they govern. A mature implementation treats the gate decision itself as the primary artifact: a structured record assembling evidence, +confidence levels, named ownership, identified gaps, and explicit rationale before any downstream commitment is made. The decision states are specific and bounded: **go, +conditional-go, no-go, and defer**, each carrying distinct documentation requirements and escalation obligations. Full technical implementation at this level of rigor is +aspirational rather than required at the incubation stage. What is required is that the governance specification exists as a written, reviewable document, and that the project's +architecture is compatible with its enforcement as institutional capacity develops. --- ## Gate 2: Graduation to Active CDCF Project Status +> Graduation requires that Gate 1 criteria remain satisfied in full and that the following two additional requirements are met. These requirements address operational readiness: +> the difference between a project that performs well in a controlled context and one that Catholic institutions can adopt, maintain, and trust at scale. + +--- + ### Criterion 7: Documentation for Independent Deployment and Data Stewardship -The project must provide documentation sufficient for a Catholic institution to evaluate, configure, deploy, and support the project independently. It must also demonstrate -rigorous data stewardship, complying with relevant legal and canonical requirements for data protection. +The project must carry documentation sufficient for a Catholic institution to evaluate, configure, deploy, and support the project without direct involvement from the original +submitter. This includes technical documentation, user-facing guidance, and explicit documentation of the governance specification required under Criterion 6. + +**The deployment test:** Could the director of technology at a diocesan schools office, working with their team and without access to the project's authors, deploy this project +responsibly within 90 days? + +Data stewardship requirements are proportionate to the project's risk profile. Projects that handle personal data must meet the following requirements: + +| Data Type | Compliance Requirement | +| ------------------------- | --------------------------------------------------------------------- | +| Health information | HIPAA compliance; data minimization approach documented | +| Student records | FERPA compliance; retention and deletion procedures specified | +| Sacramental data | Diocesan data governance policies; access controls documented | +| Data pertaining to minors | Enhanced protections; explicit consent and breach response procedures | +| Financial information | Applicable state and federal law; audit trail requirements | + +**AI domain extension.** For AI tools, this criterion extends to training data governance. A tool trained on data from Catholic institutions carries an obligation to those +institutions and to the populations they serve. The terms under which that data was used, and the terms under which it may be used in future model updates, must be disclosed and +evaluated as part of the graduation review. + +--- ### Criterion 8: Governance, Maintenance, and Subsidiarity Compatibility -The project must have a documented process for ongoing maintenance and community governance. It must be architecturally compatible with the principle of subsidiarity, allowing -local communities (parishes, dioceses) to retain their proper initiative and responsibility. +The project must have a defined and documented process for ongoing maintenance, version control, vulnerability response, and community governance. A named maintainer or maintainer +team must accept public accountability for the project going forward. + +The project must be deployable at the appropriate level of ecclesial authority, whether parish, diocese, or institution, without requiring centralized control that would compromise +subsidiarity. The Church's understanding of subsidiarity is precise on this point: it is a guarantee that each level of authority retains its proper duties and rights regarding the +common good, rather than a simple delegation of decisions to the lowest available level, and it ensures that no larger entity absorbs the legitimate initiative and responsibility +of smaller ones.[^9] Local communities must be able to configure the project for their context, and that configuration capacity must be architecturally genuine, requiring no +override of the project's core accountability, safety, or governance design in order to function. + +_Antiqua et Nova_ (§42) is explicit that the responsibility for managing technology wisely "pertains to every level of society, guided by the principle of subsidiarity."[^1] A +project that functions only under conditions of centralized administration concentrates authority in ways that violate this principle and undermine the ecclesial structure the CDCF +exists to serve. --- ## Grounding in Catholic Teaching and Canonical Tradition -These criteria are rooted in the Church's teaching on human dignity, the common good, and the principles of subsidiarity and solidarity. They operationalize these theological and -canonical realities into technical and organizational standards for the digital commons. +These eight criteria are grounded in three bodies of teaching held in common across the CDCF community. + +**Human dignity and genuine human control.** _Antiqua et Nova_ (Dicastery for the Doctrine of the Faith, January 2025) insists that AI must remain under genuine human moral +responsibility, distinguishes human intelligence from artificial statistical inference on anthropological and theological grounds, and establishes that "human dignity itself depends +on" maintaining real human control over technology-mediated decisions.[^1] Criteria 2 and 6 operationalize this requirement at the level of institutional deployment. + +**Subsidiarity and accountable authority.** Canon 627 of the Code of Canon Law requires that decisions be made at the appropriate level of authority with identifiable human +ownership.[^4] Canon 1609 establishes the pattern of collegiate deliberation, written conclusions, ordered discussion, and documented decision that grounds Criterion 6's governance +specification requirement.[^8] Criterion 8 extends subsidiarity from ecclesial governance into the deployment architecture of the projects themselves. + +**The common good over efficiency.** Pope Leo XIV, in his message to the Builders AI Forum (November 2025), called on technology builders to cultivate moral discernment as a +profoundly ecclesial endeavor and to develop systems that reflect justice, solidarity, and genuine reverence for life.[^2] This principle animates all eight criteria: Catholic +institutions are stewards, and stewardship requires that projects be evaluated against their effect on the full human person and the communities they serve, with cost savings and +operational throughput treated as secondary considerations. + +--- + +## Relationship to the Broader Governance Research + +These criteria represent the incubation and graduation layer of a broader governance architecture currently under discussion within U.S.A. C-DART 1 (Catholic Deep AI Research +Team), which is actively engaged in a structured planning process to evaluate and prioritize top AI trends facing Catholic institutions. Three research memos emerging from that +process inform the design of these criteria and are submitted alongside this document. + +**[Fragmented Catholic Digital Governance at Scale](../research/fragmented-catholic-digital-governance.md)** documents why Catholic institutions across dioceses, health systems, +and education networks are producing dozens of incompatible governance standards and digital representations for structurally identical use cases, and why shared canonical +baselines are urgent. This research provides the empirical foundation for the criteria's design. + +**[Governance-as-Code for Catholic Technology Deployment](../research/governance-as-code-catholic-technology.md)** argues that deployment policies should become machine-readable, +auditable specifications operating as hard gates rather than advisory documents. This research informs Criterion 6's governance specification requirement and describes the more +technically rigorous implementation this framework is designed to grow into. + +**[Trusted Data Infrastructure for Catholic Ministry](../research/trusted-data-infrastructure-catholic-ministry.md)** addresses the data infrastructure — both synthetic +institutional data and standardized ecclesial data — that would enable responsible technology development across Catholic health, education, social services, and parish life. +This research grounds Criterion 7's extended data stewardship requirements and anticipates the data governance obligations accompanying more sophisticated Catholic technology +development. + +--- + +## An Invitation to Iterate + +This is a working draft. Every criterion is a proposal subject to revision through community input, pilot experience, and dialogue with ecclesial advisors. The goal is a living +standard that grows more precise and more useful as Catholic institutions begin applying it to real projects. + +Contributions, challenges, and proposed revisions are welcome via pull request or issue on the [CatholicOS GitHub](https://github.com/CatholicOS). + +_Drafted in dialogue with U.S.A. C-DART 1 (Catholic Deep AI Research Team). February–March 2026._ + +--- + +## Bibliography + +[^1]: + Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human + Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), + https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. + +[^2]: + Pope Leo XIV, "Message to Participants in the Builders AI Forum 2025," Vatican City, November 3, 2025, + https://www.vatican.va/content/leo-xiv/en/messages/pont-messages/2025/documents/20251103-messaggio-builders-aiforum.html. + +[^3]: + "The Real Lesson Behind the 'Father Justin' AI Priest Debacle," _America_, April 26, 2024, + https://www.americamagazine.org/faith/2024/04/26/father-justin-catholic-answers-ai-247808. + +[^4]: _Code of Canon Law_, Canon 627 (Vatican City: Libreria Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib2-cann460-572_en.html. + +[^5]: Commonwealth of Australia, _Royal Commission into the Robodebt Scheme: Final Report_ (Canberra: Commonwealth of Australia, 2023), https://robodebt.royalcommission.gov.au/. + +[^6]: + Julia Angwin, Jeff Larson, Surya Mattu, and Lauren Kirchner, "Machine Bias," _ProPublica_, May 23, 2016, + https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing. + +[^7]: + Pope Leo XIV, "Address to Participants in the Conference 'Artificial Intelligence and Care for Our Common Home,'" Vatican City, December 5, 2025, + https://www.vatican.va/content/leo-xiv/en/speeches/2025/december/documents/20251205-conferenza.html. + +[^8]: + _Code of Canon Law_, Canon 1609 (Vatican City: Libreria Editrice Vaticana, 1983), + https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html. + +[^9]: _Catechism of the Catholic Church_, 2nd ed., §1894 (Vatican City: Libreria Editrice Vaticana, 1997), https://www.vatican.va/archive/ENG0015/_INDEX.HTM. diff --git a/research/fragmented-catholic-digital-governance.md b/research/fragmented-catholic-digital-governance.md new file mode 100644 index 0000000..ffbf79f --- /dev/null +++ b/research/fragmented-catholic-digital-governance.md @@ -0,0 +1,303 @@ +# Fragmented Catholic Digital Governance at Scale + +| | | +| :---------------- | :------------------------------------------------------------------------------------------------------------------------ | +| **Document type** | Research memo | +| **Status** | Working draft — U.S.A. C-DART 1 discussion | +| **Relationship** | Supplementary research underlying [CDCF Project Vetting Criteria v0.2](../project-governance/project-vetting-criteria.md) | + +--- + +## Table of Contents + +1. [The Problem in One Sentence](#the-problem-in-one-sentence) +2. [Why Catholic Institutions Are Uniquely Exposed](#why-catholic-institutions-are-uniquely-exposed) +3. [What Fragmentation Looks Like in Practice](#what-fragmentation-looks-like-in-practice) +4. [Fragmentation Beyond AI: The Shared Digital Infrastructure of the Church](#fragmentation-beyond-ai-the-shared-digital-infrastructure-of-the-church) +5. [AI Governance Case Study: Three Dioceses Building in Isolation](#ai-governance-case-study-three-dioceses-building-in-isolation) +6. [The Acceleration Curve](#the-acceleration-curve) +7. [Subsidiarity Without Solidarity](#subsidiarity-without-solidarity) +8. [What a Shared Canonical Standard Provides](#what-a-shared-canonical-standard-provides) +9. [Relationship to the CDCF](#relationship-to-the-cdcf) +10. [Bibliography](#bibliography) + +--- + +## The Problem in One Sentence + +Catholic institutions serving tens of millions of people worldwide are digitizing, deploying technology, and building digital infrastructure independently, producing governance +regimes and data models that are incompatible with each other, cannot be jointly audited or exchanged, and will be structurally difficult to unify once entrenched vendor +relationships, diocesan contracts, and isolated implementations are in place. + +--- + +## Why Catholic Institutions Are Uniquely Exposed + +Catholic institutions occupy an unusual position in the technology governance landscape. They are simultaneously subject to civil regulation, diocesan canonical authority, and the +moral theology of the Magisterium. No secular institution faces that combination. A hospital system deploying an AI triage tool must satisfy HIPAA, the FDA's Software as a Medical +Device framework, its diocesan bishop's authority over pastoral matters, and Catholic Social Teaching's account of human dignity and the common good, all in a single deployment +decision. A developer building a liturgical calendar application must navigate the complexity of the Roman Rite across multiple editions, vernacular translations, proper calendars +for dioceses and religious orders, and the authoritative norms of the Congregation for Divine Worship — with no shared digital standard defining how any of those realities are +identified or represented in code. + +This exposure operates across two distinct but related axes. + +**Technology deployment.** The U.S. and China regulatory frameworks for AI are diverging in ways that compound institutional exposure. U.S. efforts emphasize system- and risk-based +regulation, while Chinese rules place relatively greater emphasis on content, security, and outputs.[^1] Catholic institutions operating internationally, and those receiving +federal funding domestically, face both frameworks without clarity on how to reconcile them with canonical requirements. + +**Digital infrastructure.** The realities of Catholic life that technology must represent — the Liturgy, Sacred Scripture, the Magisterium, Canon Law, diocesan and parish +structures — belong to the universal Church. They are not local inventions. Yet the process of digitizing these realities has proceeded without coordination, producing dozens of +incompatible representations of the same shared patrimony. Every liturgical software project defines its own feast identifiers. Every Bible application references Scripture +editions differently. Every diocesan database uses its own parish numbering scheme. The fragmentation is not a failure of any individual project; it is the predictable consequence +of digitization proceeding without shared standards. + +The result is that Catholic institutions are caught between competing regulatory logics for their technology deployments and incompatible data models for their shared digital +infrastructure, without a shared canonical protocol that could provide coherent guidance across either dimension. + +--- + +## What Fragmentation Looks Like in Practice + +### AI Tool Deployment + +The fragmentation in AI governance is already producing concrete operational problems across the three primary institutional domains. + +| Domain | Scale | Fragmentation Impact | +| :------------------ | :----------------------------------------- | :-------------------------------------------------------------------------------------- | +| **Healthcare** | CommonSpirit: 24 states, multiple dioceses | Same tool, same patients, same mission — blocked or reconfigured at every diocesan line | +| **Education** | 5,905 Catholic schools nationally | Vendors face dozens of incompatible standards or default to generic secular products | +| **Social Services** | 168 Catholic Charities agencies | Cannot share tools, compare outcomes, or build on each other's governance work | + +**Healthcare.** CommonSpirit Health operates in 24 states across multiple dioceses.[^2] A single AI-assisted triage or clinical decision support tool cannot be deployed uniformly +across that system because each diocese it operates in carries different consent requirements, different pastoral boundary definitions, and different data governance expectations +developed independently. The same tool, the same patients, the same mission, reconfigured or legally blocked every time it crosses a diocesan line. + +**Education.** A vendor trying to serve all 5,905 Catholic schools in the United States[^3] faces dozens of incompatible responsible Catholic AI evaluation standards, each +developed by a different diocesan office operating without reference to the others. The vendor's options are to build bespoke configurations for every diocese, which is expensive +and unsustainable at scale, or to ignore Catholic-specific requirements entirely and deploy a generic secular product. The second outcome is precisely what Catholic governance +exists to prevent. + +**Social services.** The 168 Catholic Charities agencies operating across the country[^4] cannot share AI tools, cannot compare program outcomes across jurisdictions, and cannot +build on each other's governance work, because the regulatory and canonical regimes they operate under are incompatible. An AI intake screening tool that passes muster in one +diocese may be blocked in a neighboring one under criteria that were never designed to be interoperable. + +### Shared Digital Infrastructure + +The same pattern of fragmentation is visible — and in some cases far more entrenched — in the digital representation of realities that belong to the universal Church. + +| Domain | What Is Shared | What Is Fragmented | +| :---------------------------- | :------------------------------------------------------------------ | :---------------------------------------------------------------------------------- | +| **Liturgy** | The Roman Rite, the General Roman Calendar, proper calendars | Every app defines its own feast identifiers, calendar logic, and data structures | +| **Sacred Scripture** | The approved texts and editions of the Catholic Bible | Every platform references editions, books, and verses in its own schema | +| **Magisterial Documents** | Encyclicals, apostolic constitutions, decrees of the Magisterium | No shared digital identifiers for document types, issuers, or authority levels | +| **Canonical Structures** | Dioceses, parishes, religious institutes, ecclesial movements | Every database uses its own numbering; no canonical digital directory exists | +| **Sacramental Records** | The Church's sacramental register system | Diocesan databases are mutually incompatible; no data exchange standard exists | + +These are not peripheral concerns. The Liturgy, the Bible, Canon Law, and the Magisterium constitute the shared patrimony of the universal Church. Their digitization is not +optional — it is already happening, in hundreds of independent projects worldwide. The question is whether that digitization proceeds under shared standards that preserve the +ecclesial unity of what is being represented, or whether the digital Church fragments into incompatible local implementations of universal realities. + +--- + +## Fragmentation Beyond AI: The Shared Digital Infrastructure of the Church + +The AI governance fragmentation documented above is urgent and visible, but it is a specific instance of a deeper structural problem. The realities of Catholic life that technology +must represent are shared across the entire Church. They require collaboration and coordination between Church institutions — assisted by specialized technologists — for the +processes of digitization, digital standardization, and distribution. When that collaboration does not exist, fragmentation is the inevitable result. + +**Liturgical calendars.** Multiple independent implementations of the Roman Calendar exist (among them the LitCal API, RomCal, and ePrex), each defining its own identifiers for +liturgical celebrations, its own data structures for feast rankings and seasonal cycles, and its own approach to representing the proper calendars of dioceses and religious orders. +A parish using one liturgical software cannot exchange calendar data with a diocesan system built on another. The General Roman Calendar is universal; its digital representations +are not. + +**Sacred Scripture editions.** The Catholic Church has approved numerous editions and translations of the Bible throughout its history, from the Vulgate through the Nova Vulgata to +dozens of vernacular translations. Every Catholic Bible application, every liturgical reading tool, and every catechetical platform that references Scripture has had to invent its +own way of identifying which edition it is working with. There is no shared registry of Catholic Bible editions, no standard identifier scheme, and no interoperability between +systems that reference the same texts. + +**Magisterial documents.** The documents of the Magisterium — encyclicals, apostolic constitutions, motu proprii, conciliar decrees, dicastery instructions — are among the most +authoritative texts in Catholic life. Yet there is no shared digital scheme for identifying them by type, issuing authority, or magisterial weight. Every project that needs to +reference a Magisterial document must create its own classification from scratch. + +**Canonical structures.** The Church's organizational structure — dioceses, eparchies, archdioceses, parishes, religious institutes, ecclesial movements — has no shared digital +directory with stable identifiers. Diocesan databases, national directories, and Vatican records each use their own numbering schemes. Historical entities that have been merged, +suppressed, or renamed compound the complexity. A researcher or developer seeking to build software that operates across diocesan boundaries has no canonical digital reference +point. + +The common thread is that each of these domains represents a shared reality of the universal Church being digitized independently by dozens of actors, producing incompatible +representations that cannot interoperate. The governance problem is identical in structure to the AI fragmentation: subsidiarity without solidarity produces local solutions that +cannot serve the universal Church. + +--- + +## AI Governance Case Study: Three Dioceses Building in Isolation + +Three U.S. dioceses built formal AI governance structures between 2024 and 2026. Each represents a serious, good-faith effort. None was built with reference to the others, and the +three models are structurally incompatible. + +| Diocese | Year | Governance Model | Instrument | +| :------------------- | :-------------------- | :---------------------------------------------- | :------------------------------- | +| Diocese of Orange | 2024 | Standing council with quarterly review | Living guidebook document | +| Diocese of Biloxi | Effective Jan 1, 2026 | Episcopal decree (binding canonical instrument) | Signed by Bishop Kihneman | +| Diocese of Arlington | June 2025 | Educator-led working group | School-specific policy framework | + +**Diocese of Orange (2024).**[^5] Established a standing Diocesan AI Council composed of the Vicar General, IT Director, HR, Communications, and parish pastors. The Council +maintains a living document guidebook and meets quarterly to review AI developments across diocesan operations, ministry, and education. + +**Diocese of Biloxi (effective January 1, 2026).**[^6] Issued an Episcopal Decree signed by Bishop Kihneman, a binding canonical instrument applying to all clergy, religious, lay +employees, and volunteers across the diocese. This appears to be the first formal episcopal AI decree in the United States. + +**Diocese of Arlington (June 2025).**[^7] Formed a 14-person working group of Catholic school educators who developed an AI policy framework distributed to Catholic schools across +the diocese, presented at a regional conference in August 2025. + +Three governance models with no shared evaluation standards, no common definition of what constitutes a permissible AI application, and no coordination mechanism. A vendor +evaluated favorably under Orange's council process has no assurance of meeting Biloxi's episcopal requirements or Arlington's school-specific framework. + +This case study illustrates the AI-specific instance of the broader pattern: when institutions with shared mission and shared canonical obligations build governance structures +independently, the result is incompatibility at the exact boundaries where interoperability matters most. + +--- + +## The Acceleration Curve + +The fragmentation problem is active and accelerating across both dimensions. + +**AI deployment** in enterprise and institutional contexts moved from prototype to viral adoption in approximately 60 days in several documented cases in 2024 and 2025.[^8] +Catholic institutions are operating on a 12–18 month lag behind commercial deployment curves, which means the governance window is narrow and closing. Every month that passes +without a shared canonical governance process, another diocese builds something incompatible. Vendors begin designing products to the fragmented landscape rather than to a unified +Catholic standard. Contracts get signed. Systems get deployed. Technical debt accumulates. + +**Digital infrastructure** fragmentation operates on a longer but equally consequential timeline. Every liturgical software project that launches with its own identifier scheme, +every diocesan database that defines its own parish numbering, every Bible application that invents its own edition references — each one deepens the fragmentation. Unlike AI +tools, which can be replaced, data models and identifier schemes become load-bearing infrastructure that downstream systems depend on. Migrating from a fragmented identifier +scheme to a shared standard is orders of magnitude more difficult than adopting a shared standard before the fragmented one takes root. + +What begins as a coordination gap becomes a structural feature of Catholic digital governance that will require decades to unwind. + +--- + +## Subsidiarity Without Solidarity + +The fragmentation is the predictable outcome of subsidiarity operating without a solidarity layer, produced by good-faith institutional actors working independently rather than by +governance failure. + +_Antiqua et Nova_ (§42) affirms that the responsibility for managing AI wisely "pertains to every level of society, guided by the principle of subsidiarity."[^9] Dioceses building +their own governance structures — whether for AI tools or for local technology projects — are doing exactly what subsidiarity asks them to do. The problem is that subsidiarity +without a shared canonical foundation produces incompatible local standards that cannot serve institutions like CommonSpirit or the Catholic Charities network, which operate across +diocesan lines, nor the universal Church, whose shared patrimony requires shared digital representations. + +Catholic Social Teaching is precise on this point. _Mensuram Bonam_ articulates that subsidiarity is considerably more than simple delegation, which often allows larger bodies to +retain power and ultimate control. Authentic subsidiarity "distributes roles and power horizontally, creating mutual accountability from all levels towards the common good."[^10] +Fragmented diocesan governance models and incompatible digital implementations are therefore not simply a failure of coordination; they represent a failure to execute the horizontal +mutual accountability that subsidiarity itself requires. The CDCF is designed to fulfill that requirement: preserving local authority while establishing the mutual accountability +that isolated local action cannot provide. + +The Magisterium has provided rich doctrinal grounding for why human dignity, moral agency, and genuine human control over technology matter (_Antiqua et Nova_ is precise and +substantial on these points).[^9] Operational protocols that translate those principles into shared canonical governance processes and shared digital standards remain to be +developed. A diocese receiving a vendor proposal for its schools or hospitals has principle-level guidance and no procedural framework for acting on it. A developer building +liturgical software has the texts of the Roman Rite and no shared digital standard for representing them. + +The USCCB's joint letter on AI principles warns explicitly that automated decision-making systems used in employment screening, healthcare, public benefit screening, and related +domains "can reinforce existing biases or introduce a utilitarian approach devoid of necessary human considerations, with potentially devastating consequences."[^11] The letter +affirms the importance of ethical principles and reasonable policy, and it, too, stops short of a shared operational standard. + +The gap between principle and protocol is the specific problem this research addresses. Subsidiarity requires that local institutions govern themselves. Solidarity requires that +they do so within a framework coherent enough to serve the universal Church. Shared vetting standards and shared digital standards preserve diocesan authority while providing the +solidarity layer that makes local authority coherent at scale. + +--- + +## What a Shared Canonical Standard Provides + +Shared standards — for technology governance and for the digital representation of Catholic realities — resolve the fragmentation problem at the points where it is most tractable. + +**For technology deployment,** a shared vetting standard resolves fragmentation at the evaluation stage, before tools are deployed. Rather than requiring every diocese to develop +its own evaluation methodology from scratch, a shared standard provides a common baseline that any diocese can adopt, adapt for local context, and apply consistently. Vendors +evaluated against the shared standard have assurance of meeting Catholic institutional requirements across diocesan lines. Institutions operating across multiple dioceses, +including health systems, Catholic Charities networks, and school systems, can deploy tools under a single governance framework rather than reconfiguring for every jurisdiction. + +**For shared digital infrastructure,** canonical data standards resolve fragmentation at the representation layer, before incompatible implementations become entrenched. A shared +identifier scheme for liturgical celebrations means that any liturgical software project can exchange data with any other. A shared registry of Catholic Bible editions means that +Scripture references are portable across applications. A shared digital directory of dioceses and parishes means that systems built in different jurisdictions can interoperate by +default. Each standard reduces the cost of building Catholic software, eliminates redundant effort, and ensures that the digital representation of the Church's shared patrimony +reflects the ecclesial unity of what it represents. + +Both categories of standard also function as market safeguards. Pope Leo XIV has demanded that technology governance ensure technology "truly serves the common good, and is not +just used to accumulate wealth and power in the hands of a few."[^12] A fragmented landscape — whether of diocesan AI policies or of incompatible liturgical data models — is +precisely the condition that allows vendors to exploit incompatible standards, accumulating data and market position at the expense of local ministries. Shared canonical standards +close that opening. + +_Antiqua et Nova_ further establishes that "greater autonomy heightens each person's responsibility across various aspects of communal life."[^9] Catholic institutions exercise +immense autonomy worldwide. That autonomy carries a correspondingly serious responsibility to demonstrate that their capacities are used in the service of others. Shared standards +are the operational proof that Catholic institutions recognize and act on that responsibility. + +--- + +## Relationship to the CDCF + +The research documented here provides the empirical foundation for two complementary CDCF programs. + +**The [CDCF Project Vetting Criteria](../project-governance/project-vetting-criteria.md)** represent the operational response to technology deployment fragmentation. The eight +criteria, organized across two evaluation gates, establish a shared baseline for what "vetted" means for technology projects submitted to the Catholic Digital Commons Foundation. +The criteria are designed to be adoptable by any diocese, health system, or Catholic institution regardless of which local governance model they operate under, whether standing +council, episcopal decree, educator working group, or other. + +**The [CDCF Standards program](../standards/overview.md)** represents the operational response to digital infrastructure fragmentation. By establishing shared, canonical +identifiers and data representations for the entities and realities of Catholic life — beginning with liturgical celebrations, Magisterial documents, and Roman Missal editions — +the standards program provides the solidarity layer that allows independent software projects to interoperate. Standards committees, composed of ecclesial authorities, academic +experts, Catholic university computer science departments, and practitioners, ensure that the digital representations faithfully reflect the Church's own understanding of its +structures, rites, and traditions. + +Together, the vetting criteria and the standards program address the two dimensions of fragmentation documented in this memo: governance of the tools Catholic institutions deploy, +and interoperability of the digital infrastructure those tools operate on. + +--- + +## Bibliography + +[^1]: + Oliver Guest and Kevin Wei, _Bridging the Artificial Intelligence Governance Gap: The United States' and China's Divergent Approaches to Governing General-Purpose Artificial + Intelligence_, Perspective PE-A3703-1 (Santa Monica, CA: RAND Corporation, December 2024), https://www.rand.org/pubs/perspectives/PEA3703-1.html. + +[^2]: + CommonSpirit Health, _Audited Consolidated Financial Statements as of and for the Years Ended June 30, 2024 and 2023_ (Chicago: CommonSpirit Health, 2024), + https://www.commonspirit.org/content/dam/shared/en/pdfs/investor-resources/2024-CommonSpirit-Health-Annual-Report.SECURED.pdf. + +[^3]: + National Catholic Educational Association, _United States Catholic Elementary and Secondary Schools 2023–2024: The Annual Statistical Report on Schools, Enrollment and + Staffing_ (Arlington, VA: NCEA, 2024), https://www.ncea.org/NCEA/NCEA/Who_We_Are/About_Catholic_Schools/Catholic_School_Data/Catholic_School_Data.aspx. + +[^4]: + Catholic Charities USA, _Pathways Forward: 2024 Annual Report_ (Alexandria, VA: Catholic Charities USA, 2025), + https://www.catholiccharitiesusa.org/publications/2024-annual-report/. + +[^5]: Diocese of Orange, "Diocesan AI Council," Roman Catholic Diocese of Orange, 2024, https://www.rcbo.org/ministry/artificial-intelligence-ai-council/. + +[^6]: Diocese of Biloxi, Episcopal Decree on Artificial Intelligence, signed by Bishop Louis F. Kihneman III, effective January 1, 2026, https://biloxidiocese.org/officials. + +[^7]: + "Catholic Schools Take Initiative in AI Challenge," _Catholic Herald_, June 2025, + https://www.catholicherald.com/article/local/catholic-schools-take-initiative-in-ai-challenge/. The policy framework referenced was developed by a 14-person educator working + group convened by the Diocese of Arlington and presented at a regional conference in August 2025. + +[^8]: + Ian Mitch, Matthew J. Malone, Karen Schwindt, Gregory Smith, Wesley Hurd, Henry Alexander Bradley, and James Gimbi, _Governance Approaches to Securing Frontier AI_, Research + Report RR-A4159-1 (Santa Monica, CA: RAND Corporation, 2025), https://www.rand.org/pubs/research_reports/RRA4159-1.html. + +[^9]: + Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human + Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), + https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. + +[^10]: + Pontifical Academy of Social Sciences, _Mensuram Bonam: Faith-Based Measures for Catholic Investors_ (Vatican City: Pontifical Academy of Social Sciences, 2022), + https://www.vatican.va/roman_curia/pontifical_academies/acdscien/documents/mensuram-bonam_en.html. + +[^11]: + United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, + https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. + +[^12]: + Pope Leo XIV, "Message to Participants in the Builders AI Forum 2025," Vatican City, November 3, 2025, + https://www.vatican.va/content/leo-xiv/en/messages/pont-messages/2025/documents/20251103-messaggio-builders-aiforum.html. diff --git a/research/governance-as-code-catholic-technology.md b/research/governance-as-code-catholic-technology.md new file mode 100644 index 0000000..44a1e1c --- /dev/null +++ b/research/governance-as-code-catholic-technology.md @@ -0,0 +1,288 @@ +# Governance-as-Code for Catholic Technology Deployment + +| | | +| :---------------- | :------------------------------------------------------------------------------------------------------------------------ | +| **Document type** | Research memo | +| **Status** | Working draft — U.S.A. C-DART 1 discussion | +| **Relationship** | Supplementary research underlying [CDCF Project Vetting Criteria v0.2](../project-governance/project-vetting-criteria.md) | + +--- + +## Table of Contents + +1. [The Core Argument](#the-core-argument) +2. [What Governance-as-Code Is](#what-governance-as-code-is) +3. [Why Catholic Institutions Need It](#why-catholic-institutions-need-it) +4. [The Three-Layer Stack](#the-three-layer-stack) +5. [The Gate Decision as Primary Artifact](#the-gate-decision-as-primary-artifact) +6. [Application to AI Deployment](#application-to-ai-deployment) +7. [Application to Standards Compliance](#application-to-standards-compliance) +8. [Honest Assessment of Institutional Readiness](#honest-assessment-of-institutional-readiness) +9. [What Catholic Institutions Can Do Now](#what-catholic-institutions-can-do-now) +10. [Relationship to the CDCF](#relationship-to-the-cdcf) +11. [Bibliography](#bibliography) + +--- + +## The Core Argument + +Technology governance in Catholic institutions currently lives in PDFs and committee meetings. When a diocese, school, or Catholic hospital deploys a technology system — whether an +AI tool, a parish management platform, a data-sharing integration, or a liturgical software project — the governance process typically produces a document that says the system is +approved. That document exists separately from the system it governs. It cannot prevent a non-compliant deployment. It cannot be automatically validated. It can only react after +something goes wrong. + +Governance-as-code is the practice of turning those policy documents into machine-executable specifications wired directly into deployment pipelines. The governance becomes part of +the infrastructure. This shift is already occurring in regulated enterprise environments. The question for Catholic institutions is whether they participate in shaping what those +specifications encode, or whether they inherit secular governance schemas designed without reference to Catholic moral theology, canonical authority, or the Church's preferential +concern for the vulnerable. + +The principle applies across two dimensions of the CDCF's mission. For **technology deployments**, governance-as-code enforces the vetting criteria as hard gates before any project +reaches production. For **standards compliance**, governance-as-code verifies that projects conform to CDCF data standards — the shared identifiers and representations for +liturgical celebrations, Magisterial documents, Scripture editions, and canonical structures — automatically and continuously. + +--- + +## What Governance-as-Code Is + +In a governance-as-code architecture, policy requirements are expressed as version-controlled schemas (typically JSON or YAML) that define exactly what a technology system must +demonstrate before it can reach production. When a developer attempts to deploy a project, the deployment pipeline calls those schemas as hard gates. + +The gate logic is deterministic. Pass all gates and the project deploys. Fail any gate and it does not. Every decision, pass or fail, is logged in an immutable audit trail that +regulators, diocesan authorities, or institutional leadership can examine after the fact. + +The schemas themselves define the governance criteria: what evidence of testing is required, what data domains the system is permitted to touch, what level of human oversight it +operates under, who the named accountable person is, what conditions require escalation to a higher authority, and — for projects in domains covered by CDCF standards — whether the +project's data representations conform to the canonical schemas. These are the same questions the CDCF Vetting Criteria ask. Governance-as-code is the technical architecture that +makes those questions into enforceable gates rather than advisory checklists. + +This is distinct from using AI to govern technology. The gate decision in a governance-as-code architecture is deterministic: a schema either passes or it does not, based on +explicit criteria defined in advance by human authorities. AI can assist with evidence synthesis and risk surfacing within the pipeline, but the gate logic itself remains under +human-defined, machine-enforced control. + +A structural concern across all technology governance is the compliance gap between regulatory intent and deployment practice. Current governance frameworks share three recurring +gaps: scope ambiguity in defining covered systems, point-in-time compliance requirements that fail to address systems that evolve after initial approval, and information +asymmetries between regulators and deploying institutions.[^1] Governance-as-code directly addresses all three: schema definitions establish scope with precision, +version-controlled schemas evolve with the system they govern, and immutable audit trails close the information gap. + +The Commission of the Bishops' Conferences of the European Union (COMECE) affirms that evaluating technology from an ethical perspective "requires internal control principles and +risk assessment in addition to legislation."[^2] Governance-as-code is the direct instantiation of those mandated internal control principles, translating ethical evaluation from a +periodic review activity into a continuous, enforceable infrastructure requirement. + +--- + +## Why Catholic Institutions Need It + +The fragmentation problem documented in the companion memo on [Catholic digital governance at scale](./fragmented-catholic-digital-governance.md) is fundamentally a governance +encoding problem — across both technology deployment and digital infrastructure. + +**Technology deployment.** Each diocese is expressing its Catholic technology governance values in a different format, at a different level of specificity, for different audiences. +Orange wrote a council charter. Biloxi wrote a decree. Arlington wrote school policy. None of those instruments are machine-readable. None of them can be automatically validated +against. A vendor can acknowledge all three documents and deploy a non-compliant system anyway, because the documents have no technical enforcement mechanism. + +**Standards compliance.** The same problem applies to digital standards. Even when shared canonical identifiers exist for liturgical celebrations, Magisterial documents, or +Scripture editions, a project can claim compliance without being verified. Without machine-enforceable schemas defining what conformance to a CDCF standard looks like, standards +adoption depends on voluntary discipline rather than architectural enforcement. + +Governance-as-code changes both structural relationships. A shared canonical governance schema — a baseline set of machine-executable policies encoding the principles of _Antiqua +et Nova_,[^3] the USCCB principles,[^4] the Ethical and Religious Directives, and the CDCF data standards into version-controlled, reusable specifications — would let any diocese +adopt the shared baseline and extend it with local requirements. Subsidiarity is preserved because local authority still governs local decisions. Solidarity is achieved because +every institution operating on the shared baseline is interoperable. + +A vendor serving Catholic schools would face one canonical schema with optional diocesan extensions rather than dozens of incompatible checklists. A Catholic hospital system +operating across diocesan lines could deploy uniformly because the governance infrastructure is compatible across jurisdictions. A liturgical software project could verify its +conformance to CDCF calendar identifiers as part of every build. The governance becomes as portable as the tools it governs. + +The _Rome Call for AI Ethics_ demands that principles and values be instilled into a framework that "acts as a point of reference for digital ethics, guiding our actions and +promoting the use of technology to benefit humanity."[^5] The governance platform layer of this architecture directly answers that call, creating a shared, tangible reference point +for digital ethics that is enforceable across Catholic institutional boundaries rather than aspirational. + +--- + +## The Three-Layer Stack + +A mature governance-as-code architecture for Catholic technology deployment operates across three layers, each serving a distinct institutional function. + +| Layer | Function | Primary Users | CDCF Role | +| :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------- | :------------------------------------- | +| **Infrastructure** | CI/CD pipeline hooks, Kubernetes admission controllers, deployment gate logic, standards validation checks. Where schemas execute as hard gates and audit trails are generated. | Developers and DevOps teams | Contributes schema specifications | +| **Governance Platform** | Schema library: version-controlled policy specifications, risk classification logic, canonical Catholic governance baseline, CDCF standards conformance schemas. Where Catholic moral theology and canonical requirements are encoded as machine-readable criteria. | Diocesan IT offices and governance leads | Stewards the shared canonical baseline | +| **Application** | Institutional-facing tools: onboarding workflows, risk dashboards, standards compliance reports, audit artifacts for diocesan leadership and external regulators. | Parish and school administrators | Provides templates and tooling | + +These three layers correspond directly to the three levels of institutional capacity Catholic organizations actually have. A small parish or school operates primarily at the +application layer, using governance tools without needing to understand the infrastructure underneath. A diocesan IT office operates at the governance platform layer, adopting and +extending canonical schemas for local context. A large Catholic health system or university operates at the infrastructure layer, embedding governance gates into its own CI/CD +pipelines. + +--- + +## The Gate Decision as Primary Artifact + +The most significant design principle in this framework is that the gate decision itself, the go, conditional-go, no-go, or defer determination, is treated as a first-class +artifact rather than a byproduct of the review process. + +A gate decision artifact captures the specific evidence assembled, the confidence levels assigned, the gaps identified, the named human decision owner, the rationale for the +outcome, and the conditions under which the decision was made. It is immutable once recorded. It is the document that answers the regulator's question, the bishop's question, and +the affected person's question: why was this system deployed, under whose authority, and on what basis. + +This design directly reflects the canonical standard established in Canon 1609, which requires that deliberative processes produce written conclusions with reasons in law and in +fact, and that the capacity for review and appeal be preserved.[^6] A gate decision artifact is the technical implementation of that canonical requirement. + +The immutability of the audit trail also serves a specifically Catholic institutional concern. The USCCB warns that technology can be misused to "undermine the dignity of persons +and respect for the truth" through the manipulation of information.[^4] An immutable gate decision record ensures that if a deployed system behaves contrary to its governance +specification, institutional accountability is clear, traceable, and preserved for review. The practical consequence of ungoverned audit trails is documented in enterprise +deployments: when a production system retrieves a superseded policy document with no captured provenance, the organization cannot reconstruct what the system saw or why, turning +incident response into forensic guesswork rather than evidence-based accountability.[^7] + +The four decision states carry distinct implications. + +| Decision State | Meaning | Documentation Requirement | +| :----------------- | :------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------- | +| **Go** | All governance criteria satisfied; deployment authorized | Full criteria evidence recorded | +| **Conditional-go** | Deployment authorized subject to specific conditions within a defined timeframe | Conditions and timeline specified; typically used when independent validation is pending | +| **No-go** | One or more criteria fell short; deployment blocked | Specific criteria and evidence gaps documented | +| **Defer** | Escalation to higher authority required before proceeding | Authority identified and reason specified | + +--- + +## Application to AI Deployment + +AI deployment is the domain where governance-as-code is most urgent and most technically mature. + +Researchers studying multi-agent system failures have identified 14 distinct failure modes across three categories (system design issues, inter-agent misalignment, and task +verification breakdowns) underscoring the structural importance of deterministic gate logic rather than agent-mediated compliance review.[^8] Empirical survey data from 306 AI +practitioners across 26 domains confirms that reliability remains the top deployment challenge, with 68 percent of production agents executing ten or fewer steps before human +intervention is required.[^9] These findings argue for governance architectures in which human-defined, machine-enforced gates are the primary control mechanism rather than agent +judgment. + +The regulatory pressure compounds the urgency. The EU AI Act, with key obligations for high-risk AI systems taking effect in 2026, creates structural demand for auditable +deployment governance in high-risk AI categories.[^10] Catholic healthcare, education, and social services operate squarely in those categories. + +| Framework | Jurisdiction | Key Gap | +| :------------------------- | :---------------- | :----------------------------------------------------- | +| California SB 53 | U.S. (California) | Scope ambiguity for covered systems | +| New York RAISE Act | U.S. (New York) | Point-in-time compliance, no post-approval tracking | +| U.S. AIREA | Federal | Information asymmetry between regulators and deployers | +| EU AI Act GPAI obligations | European Union | All three gaps present at scale | + +An AI-specific governance-as-code implementation encodes the AI domain extensions from the CDCF Vetting Criteria — training data disclosure, subgroup performance analysis, +canonical boundary conditions — as machine-enforceable schemas within the shared canonical baseline. This distinct from using AI to govern AI: the gate logic remains deterministic, +and an AI-governed pipeline would require governance of its own, creating a regress that deterministic schema enforcement avoids. + +--- + +## Application to Standards Compliance + +The governance-as-code architecture extends naturally to CDCF data standards compliance. + +When the CDCF defines canonical identifiers for liturgical celebrations (CLEDR), Magisterial documents (CMDDR), or Roman Missal editions (CRMETDR), those standards can be +expressed as machine-readable validation schemas. A liturgical software project that claims conformance to CLEDR can have that claim verified automatically in its build pipeline. +A catechetical platform that references Magisterial documents can validate its identifiers against the CMDDR schema at deployment time. + +This shifts standards compliance from a documentation claim ("we follow CDCF standards") to an architectural fact ("our pipeline verifies CDCF standards on every build"). The +governance platform layer maintains the canonical schemas, and the infrastructure layer enforces them — the same architecture that governs deployment ethics also governs data +interoperability. + +For Catholic institutions, this integration is significant. A project that passes both the vetting criteria gates and the standards conformance gates carries a level of assurance +that no policy document alone can provide: it has been validated against Catholic governance requirements and it interoperates with the shared digital infrastructure of the +Church, both verified by machine-enforceable evidence rather than self-attestation. + +--- + +## Honest Assessment of Institutional Readiness + +Full technical implementation of governance-as-code at the infrastructure layer is beyond the current capacity of most Catholic institutions, and overstating that capacity would +produce the kind of governance credibility gap this framework is designed to prevent. Most Catholic institutions, including well-resourced dioceses and health systems, currently +operate at the application layer at best. They have policy documents. Some have review committees. Very few have version-controlled governance schemas. None, to the knowledge of +this research, have canonical Catholic governance schemas embedded as hard gates in CI/CD deployment pipelines. + +That gap is the opportunity, and it is the reason the CDCF Vetting Criteria are structured as they are. Criterion 6 requires a written, reviewable governance specification and +architectural compatibility with future enforcement. Full infrastructure-layer implementation is aspirational at the incubation stage. The governance specification written today +becomes the schema encoded tomorrow. The criteria are designed to build institutional capacity progressively, meeting institutions at their current maturity rather than requiring +capabilities still to be developed. + +A critique raised in C-DART 1 session discussions is worth acknowledging directly: healthcare governance in Catholic institutions is primarily a legal and regulatory problem rather +than an engineering problem. HIPAA, FDA, CMS, and state law set the floor. That critique is accurate, and this framework accepts it. Governance-as-code operates as the technical +layer that makes compliance with those frameworks auditable, reproducible, and interoperable across Catholic institutional boundaries. The distinction between replacing regulation +and making compliance technically enforceable is the distinction that makes this approach credible rather than overreaching. + +--- + +## What Catholic Institutions Can Do Now + +Given the honest assessment of current institutional readiness, the near-term contribution of this research is a written evaluation standard that functions as the precursor to a +production CI/CD governance pipeline rather than the pipeline itself. + +The CDCF Vetting Criteria represent that evaluation standard. Criterion 6 asks submitters to specify decision authority levels, escalation conditions, human review triggers, and +appeal processes in a written, reviewable document. That specification is the first step toward a machine-executable schema. An institution that has written a rigorous governance +specification for one project has done most of the intellectual work required to encode that specification as a reusable governance schema. + +The CDCF is positioned to maintain the canonical schema library that individual institutions extend rather than build independently. That is the solidarity layer described in the +fragmentation memo: a shared baseline that preserves local authority while making Catholic technology governance interoperable at scale. + +Three concrete actions follow from this research for Catholic institutions at any level of technical maturity. + +1. **Require written governance specifications** for every technology project under evaluation. The specification format in Criterion 6 of the CDCF Vetting Criteria provides a + starting template. +2. **Version-control those specifications.** Even a Word document in a shared drive with a version number and a named owner is a meaningful step toward governance-as-code + discipline. +3. **Evaluate technology projects for schema compatibility:** does the project's architecture support governance gate integration and standards validation, or does it require + overriding governance controls to function? + +--- + +## Relationship to the CDCF + +Governance-as-code serves as the enforcement architecture for both pillars of the CDCF's mission. + +**Project vetting.** Criterion 6 of the [CDCF Project Vetting Criteria](../project-governance/project-vetting-criteria.md) is the direct operational expression of this research. +It requires a deployment governance specification as a condition of incubation acceptance, with the four-state decision model (go, conditional-go, no-go, defer) as the structural +framework for that specification. Criterion 8 extends the principle to the deployment architecture of the projects themselves, requiring that projects be deployable at the +appropriate level of ecclesial authority without overriding their core governance design. Together, Criteria 6 and 8 establish the governance specification requirements that +position Catholic institutions to adopt fuller governance-as-code implementation as institutional capacity develops. + +**Standards compliance.** The [CDCF Standards program](../standards/overview.md) defines the canonical identifiers and data representations that Catholic software projects should +adopt. Governance-as-code provides the enforcement mechanism: standards expressed as machine-readable schemas can be validated automatically, shifting compliance from +self-attestation to architectural verification. + +--- + +## Bibliography + +[^1]: + Joe Kwon and Stephen Casper, "Internal Deployment Gaps in AI Regulation," arXiv:2601.08005, submitted January 12, 2026, revised February 14, 2026, + https://arxiv.org/abs/2601.08005. + +[^2]: + Commission of the Bishops' Conferences of the European Union (COMECE), "Statement on the EU Artificial Intelligence Act," COMECE, 2024, + https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/. + +[^3]: + Dicastery for the Doctrine of the Faith and Dicastery for Culture and Education, _Antiqua et Nova: Note on the Relationship Between Artificial Intelligence and Human + Intelligence_ (Vatican City: Dicastery for the Doctrine of the Faith, January 28, 2025), + https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html. + +[^4]: + United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, + https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. + +[^5]: + Pope Francis, "Address at the Signing of the Rome Call for AI Ethics," Vatican City, February 28, 2020, + https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html. + +[^6]: + _Code of Canon Law_, Canon 1609 (Vatican City: Libreria Editrice Vaticana, 1983), + https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html. + +[^7]: Rick Hamilton, "Data Governance for AI Must Be Executable," _hamiltonandboss.com_ (Substack), 2025, https://substack.com/@rickwritesai/p-189861656. + +[^8]: + Mert Cemri, Melissa Z. Pan, Yapei Yang, Aditya Agrawal, Tatsunori Hashimoto, Diyi Yang, Qian Yang, and Percy Liang, "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657, + submitted March 17, 2025, https://arxiv.org/abs/2503.13657. + +[^9]: + Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou, and Percy Liang, "Measuring Agents in Production," arXiv:2512.04123, submitted December 2, 2025, revised + February 3, 2026, https://arxiv.org/abs/2512.04123. + +[^10]: + European Parliament and Council of the European Union, _Regulation (EU) 2024/1689 of the European Parliament and of the Council Laying Down Harmonised Rules on Artificial + Intelligence (Artificial Intelligence Act)_, Official Journal of the European Union, August 12, 2024, https://artificialintelligenceact.eu. diff --git a/research/trusted-data-infrastructure-catholic-ministry.md b/research/trusted-data-infrastructure-catholic-ministry.md new file mode 100644 index 0000000..599a6ce --- /dev/null +++ b/research/trusted-data-infrastructure-catholic-ministry.md @@ -0,0 +1,358 @@ +# Trusted Data Infrastructure for Catholic Ministry + +| | | +| :---------------- | :------------------------------------------------------------------------------------------------------------------------ | +| **Document type** | Research memo | +| **Status** | Working draft — U.S.A. C-DART 1 discussion | +| **Relationship** | Supplementary research underlying [CDCF Project Vetting Criteria v0.2](../project-governance/project-vetting-criteria.md) | + +--- + +## Table of Contents + +1. [The Core Argument](#the-core-argument) +2. [The Catholic Data Stewardship Challenge](#the-catholic-data-stewardship-challenge) +3. [Institutional Data: Scale and Sensitivity](#institutional-data-scale-and-sensitivity) +4. [Ecclesial Data: The Shared Patrimony of the Church](#ecclesial-data-the-shared-patrimony-of-the-church) +5. [Synthetic Data for AI Development](#synthetic-data-for-ai-development) +6. [What Catholic Institutions Could Build](#what-catholic-institutions-could-build) +7. [The Three-Layer Stack](#the-three-layer-stack) +8. [Three Tiers of Catholic Data](#three-tiers-of-catholic-data) +9. [The CDCF Role Across Data Tiers](#the-cdcf-role-across-data-tiers) +10. [Relationship to the CDCF](#relationship-to-the-cdcf) +11. [Bibliography](#bibliography) + +--- + +## The Core Argument + +Catholic institutions collectively hold one of the largest concentrations of data stewardship responsibilities in America — and one of the richest bodies of shared ecclesial data +in the world. These two data domains are distinct in character but face the same structural problem: the absence of shared infrastructure for governing, standardizing, and +exchanging them. + +**Institutional data** — patient records, student files, case management data, parish engagement — is sensitive, personally identifiable, and legally protected. It serves the same +overlapping populations across healthcare, education, social services, and parish life in a way no secular institution can replicate. That cross-domain view is operationally +invaluable and almost entirely inaccessible for technology development, because the data is protected by HIPAA, FERPA, diocesan privacy norms, and the pastoral trust of the people +it concerns. + +**Ecclesial data** — the Liturgy, Sacred Scripture, Magisterial documents, canonical structures — belongs to the universal Church. It is not private data but shared patrimony, +and its challenge is not privacy but standardization. Dozens of independent projects digitize these realities with incompatible identifiers, data models, and classification +schemes, producing fragmentation where the Church's own unity demands coherence. + +Both data domains require trusted infrastructure: governance frameworks, validation standards, and interoperability protocols that allow Catholic institutions to steward their data +responsibly, exchange it where appropriate, and build technology that serves their missions. This memo addresses how that infrastructure can be developed, with particular attention +to the role of synthetic data in unlocking AI development from sensitive institutional datasets. + +--- + +## The Catholic Data Stewardship Challenge + +Catholic institutions face a dual data challenge that no other class of institution shares. + +On one side, they hold massive quantities of sensitive institutional data across legally independent entities that cannot share it — even when serving the same populations and +pursuing the same mission. A family that receives care at a Catholic hospital, educates their children at a Catholic school, receives services from Catholic Charities, and +participates in parish life appears in four separate Catholic data systems. No secular institution has that cross-domain view of the same overlapping populations. That view is +precisely what makes Catholic institutional data uniquely valuable for technology development, and precisely what makes its governance obligations most serious. + +On the other side, they collectively steward the digital representations of realities that belong to the universal Church — the Roman Calendar, the editions of Sacred Scripture, +the documents of the Magisterium, the organizational structure of dioceses and parishes — but with no shared standards for how those realities are identified and represented in +code. Every liturgical software project, every Bible application, every diocesan database has had to invent its own data model for the same shared patrimony. + +The first challenge requires privacy-preserving infrastructure. The second requires standardization infrastructure. Both require the same institutional response: shared governance +frameworks developed collaboratively by Church institutions with the assistance of specialized technologists. + +--- + +## Institutional Data: Scale and Sensitivity + +The scale of Catholic institutional data stewardship in the United States is substantial. + +| Domain | Scale | Data Type | Legal Protection | +| :----------------------------- | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------- | :------------------------------------- | +| **Healthcare** | 650 hospitals · 2,200+ facilities · 1 in 7 U.S. patients · 19M emergency visits/year | EHR, clinical outcomes, demographic data | HIPAA | +| **Education** | 5,905 schools · 1.68M students · 150,000+ staff | Academic performance, behavioral, family, sacramental records | FERPA | +| **Social Services & Parishes** | 168 agencies · 28M meals · 295,000 emergency housing placements | Immigration, counseling, housing, case management, parish engagement | Diocesan privacy norms, pastoral trust | + +**Catholic healthcare** is the largest group of nonprofit healthcare providers in the United States: 650 hospitals and more than 2,200 total facilities caring for one in seven +American patients daily, with approximately 19 million emergency visits and 5.6 million hospital admissions annually.[^1] The three largest Catholic health systems (CommonSpirit +Health, Ascension, and Trinity Health) collectively operate more than 370 hospitals with combined revenues exceeding $90 billion.[^1] [^2] This data is protected by HIPAA and is +largely inaccessible for cross-institutional technology development without extended IRB processes and data sharing agreements that rarely scale. + +**Catholic education** enrolls 1.68 million students across 5,905 schools with more than 150,000 professional staff.[^3] These FERPA-protected records include academic performance, +behavioral data, family information, and, uniquely, sacramental records. The accelerating trend toward diocesan centralized management, which has grown from 2.4 percent of +elementary schools in 1990 to 18 percent in 2023, creates both opportunity and risk: centralization enables system-wide analytics but concentrates sensitive data in ways that +amplify governance obligations.[^3] + +**Catholic social services and parishes** encompass 168 Catholic Charities agencies that served more than 28 million meals and provided emergency housing to 295,000 people in 2024, +while responding to 52 disasters.[^4] Their data includes immigration records, counseling records, housing data, and case management information for some of America's most +vulnerable populations. Thousands of parishes hold additional data on the same families across giving patterns, sacramental participation, and community engagement. + +--- + +## Ecclesial Data: The Shared Patrimony of the Church + +A distinct category of data stewardship concerns the digital representation of realities that belong to the universal Church and are not private data but shared patrimony. + +| Domain | What Must Be Represented | Current State | +| :------------------------ | :----------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------- | +| **Liturgy** | The General Roman Calendar, proper calendars, feast rankings, seasonal cycles | Multiple independent implementations with incompatible identifiers | +| **Sacred Scripture** | Approved editions and translations from the Vulgate through modern vernaculars | No shared registry of editions; every application invents its own references | +| **Magisterial Documents** | Encyclicals, apostolic constitutions, conciliar decrees, dicastery instructions | No standard identifier scheme for type, issuer, or authority level | +| **Canonical Structures** | Dioceses, eparchies, parishes, religious institutes, including historical entities | Every database uses its own numbering; no canonical digital directory exists | +| **Sacramental Records** | Baptism, confirmation, marriage, ordination records maintained across diocesan register systems | Diocesan databases are mutually incompatible; no data exchange standard | + +This data does not face privacy constraints — the General Roman Calendar is public, the texts of Sacred Scripture are published, the documents of the Magisterium are freely +available. What it faces is a standardization deficit. The Church's own understanding of its structures, rites, and traditions has no authoritative digital expression that software +projects can build on. Every project that needs to reference a liturgical celebration, a Bible edition, or a Magisterial document must create its own classification from scratch. + +The consequence is the fragmentation documented in the companion memo on [Catholic digital governance at scale](./fragmented-catholic-digital-governance.md): dozens of independent +projects digitizing the same shared realities in ways that cannot interoperate, cannot be jointly validated, and cannot serve the universal Church's need for coherent digital +infrastructure. + +Trusted data infrastructure for ecclesial data means shared, canonical standards — developed by ecclesial authorities, academic experts, and specialized technologists working +together — that give the Church's shared patrimony a single, authoritative digital representation. + +--- + +## Synthetic Data for AI Development + +For sensitive institutional data, a specific technical solution has crossed the production threshold: trusted synthetic data. + +Synthetic data is algorithmically generated data that mirrors the statistical properties, distributions, and relationships of a real dataset without containing any actual records +from real individuals. A synthetic patient cohort drawn from a hospital system's electronic health records preserves the clinical patterns, demographic distributions, comorbidity +relationships, and outcome rates of the real population while containing zero real patients. No individual record can be traced back to a real person because no individual record +from a real person was used to generate it. + +The distinction between synthetic data and anonymized data is consequential. Anonymized datasets remove or mask identifying fields, but the underlying records still correspond to +real individuals, and re-identification attacks have demonstrated that anonymization alone provides insufficient protection for sensitive populations. Synthetic data generates new +records from learned distributions. Re-identification risk is dramatically reduced when datasets are fully synthetic, because synthetic records carry no real-world counterparts, +but privacy still requires careful design and independent testing before the data can be trusted for consequential use. + +Quality validation is the critical governance requirement. A synthetic dataset is valuable for AI training only if it accurately preserves the statistical properties of the source +data. Validation frameworks measure fidelity (the degree to which synthetic distributions match real distributions) and privacy (the degree to which synthetic records resist +membership inference attacks). Both dimensions require rigorous, independent validation before synthetic data can be trusted for consequential AI development. + +### The market signal + +Two market signals establish that synthetic data has crossed from experimental to production-grade infrastructure. + +| Signal | Organization | Year | Significance | +| :---------------------------- | :----------------------------- | :----------- | :---------------------------------------------------------------------------------------------------------------------------- | +| NVIDIA acquires Gretel | NVIDIA / Gretel | 2025 | $320M+ acquisition positions synthetic data generation as foundational enterprise AI infrastructure, not a niche privacy tool | +| VA deploys MDClone nationally | Veterans Health Administration | 2020–present | Demonstrates production-scale synthetic health data under federal regulatory oversight | + +NVIDIA acquired Gretel, the leading synthetic data generation platform, for more than $320 million in 2025.[^5] NVIDIA's acquisition thesis was explicit: synthetic data is +essential infrastructure for AI development in regulated industries where real data is legally inaccessible or practically unavailable at the scale AI training requires. + +The U.S. Department of Veterans Affairs, through the Veterans Health Administration, has deployed MDClone as a synthetic data engine to support multiple clinical and research use +cases.[^6] The VHA deployment demonstrated that synthetic data generation can operate at national health system scale under federal regulatory oversight, with validated fidelity +sufficient to support clinical AI development and outcomes research. + +These signals matter for Catholic institutions because they establish that the technology is production-ready and that the regulatory and governance questions, while real, are +solvable. + +--- + +## What Catholic Institutions Could Build + +Trusted data infrastructure — both standardized ecclesial data and synthetic institutional data — would unlock technology development that is currently structurally impossible. + +### From synthetic institutional data + +| Use Case | Data Source | Applications Unlocked | +| :------------------------ | :------------------------------------------------ | :------------------------------------------------------------------------------------------ | +| **Healthcare** | Synthetic EHR cohorts across 650 hospitals | Diagnostic AI, clinical operations, multi-system population research | +| **Education** | Synthetic student records across 5,905 schools | Early-warning systems, retention models, system-wide benchmarking | +| **Social Services** | Synthetic case data across 168 Charities agencies | Program effectiveness, homelessness prediction, neighborhood vulnerability modeling | +| **Research Partnerships** | Cross-institutional synthetic cohorts | NIH studies, public health research, minority population outcomes | + +Synthetic EHR cohorts across 650 hospitals would enable diagnostic AI development, clinical operations optimization, and multi-system research on population patterns without +triggering PHI sharing workflows or extended IRB delays.[^1] Catholic hospitals disproportionately serve underrepresented and underserved populations that commercial AI training +datasets consistently underrepresent. Synthetic student records across 5,905 schools would allow diocesan education offices to build early-warning systems for at-risk students and +system-wide performance benchmarking without real student data ever leaving its source system.[^3] Synthetic case management data across 168 Catholic Charities agencies would +enable program effectiveness analysis and cross-agency learning without exposing individual client identities.[^4] + +The combination of social services data with parish community data creates a neighborhood-level picture of human need that has no secular equivalent. This use case is a direct +technical execution of the Church's Preferential Option for the Poor: technology systems built on this infrastructure would see and serve the marginalized without exploiting their +data, ensuring that the most vulnerable populations benefit from technology development rather than being rendered invisible by datasets that consistently underrepresent them. + +A governance obligation follows from each of these use cases. The USCCB's principles are direct: automated decision-making systems used in healthcare, education, and social +services can reinforce existing biases or introduce a utilitarian approach that displaces necessary human considerations.[^7] The USCCB further teaches that technology should +"supplement what human beings do, not replace them or their moral judgments."[^7] Models trained on Catholic synthetic data must be designed to supplement the judgment of doctors, +teachers, and social workers, and the CDCF certification criteria for applications using synthetic data should require that human professionals retain ultimate decision-making +authority. + +U.S. Catholic institutions also serve large populations of Latin American descent, particularly in healthcare and social services. The Latin American and Caribbean Episcopal +Council has called for AI applications to be critically evaluated in particular local contexts to determine whether they advance human dignity and the common good in practice.[^8] +The federated synthetic data framework provides exactly the mechanism needed to safely develop and evaluate technology serving these specific demographic communities. + +### From standardized ecclesial data + +| Use Case | Data Source | Applications Unlocked | +| :----------------------------- | :------------------------------------------------ | :----------------------------------------------------------------------------------------- | +| **Liturgical Software** | Shared CLEDR identifiers for all celebrations | Interoperable calendar apps, lectionary tools, liturgical planning systems | +| **Scripture Applications** | Shared registry of Catholic Bible editions | Cross-reference tools, liturgical reading integration, catechetical platforms | +| **Magisterial Research** | Shared CMDDR identifiers for Church documents | Citation tools, teaching authority databases, theological research platforms | +| **Diocesan Administration** | Shared identifiers for canonical structures | Cross-diocesan directories, national reporting, historical research | + +When Catholic software projects build on shared canonical identifiers rather than inventing their own, interoperability becomes the default rather than the exception. A liturgical +calendar app can exchange data with a parish management system. A catechetical platform can reference the same Magisterial documents as a theological research tool. A diocesan +database can interoperate with a national directory. Each shared standard eliminates redundant effort and ensures that the digital representation of the Church's patrimony reflects +the ecclesial unity of what it represents. + +--- + +## The Three-Layer Stack + +Trusted data infrastructure for Catholic ministry operates across three layers that correspond to institutional capacity levels. + +| Layer | Function | Primary Users | CDCF Role | +| :---------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------- | :-------------------------------------------------------------- | +| **Infrastructure** | Synthetic data generators, standards validation engines, PHI/PII-sensitive pipeline controls. Handles technical generation, validation, and standards conformance checking. | Large health systems and university research centers | Contributes validation and conformance specifications | +| **Governance Platform** | Catholic-specific governance framework encoding quality validation standards, data stewardship policies, CDCF standards schemas, and access-control patterns. | Diocesan governance offices and data stewards | Stewards validation standards, certification criteria, schemas | +| **Application** | Ready-made tools: diocesan education dashboards, Charities program evaluation tools, liturgical software using CDCF standard identifiers, parish data integrations. | Diocesan offices, parishes, small agencies | Provides certified application templates and standard schemas | + +--- + +## Three Tiers of Catholic Data + +A critique raised in C-DART 1 session discussions warrants direct acknowledgment: data heterogeneity across legally independent Catholic institutions would make a pooled Catholic +data commons technically unsound. That critique is accurate — but it applies to one category of data, not all of them. The appropriate architecture depends on what kind of data is +being governed. + +Catholic data falls into three distinct tiers, each requiring a different infrastructure model. + +### Tier 1: Sensitive institutional data — federated, never pooled + +Patient records, student files, case management data, parish giving records, and sacramental records pertaining to specific individuals are sensitive data protected by HIPAA, +FERPA, diocesan privacy norms, and pastoral trust. Catholic hospitals, schools, and Charities agencies operate under different legal entities, different regulatory frameworks, and +different diocesan governance structures. Their data schemas, data quality, and data governance norms are incompatible in ways that would produce noise rather than signal if +combined naively. + +This data is never the subject of a data commons. The architectural response is federated synthetic data generation: each institution generates synthetic datasets locally from its +own source data, and only the synthetic datasets — containing no real individual records — move between institutions or become available for research and AI development. Each +institution retains full control over its source data. + +### Tier 2: Local institutional data — locally governed, not a commons + +Operational data specific to a diocese, school system, or agency — enrollment figures, staffing models, facility data, local program configurations — is not sensitive in the same +way as personal records, but it is specific to the institution that produces it. It falls under the governance of the local institution and is not a candidate for a data commons. + +This data benefits from shared standards (so that diocesan systems can interoperate where needed) but remains locally owned and locally governed. + +### Tier 3: Universal Church data — a genuine data commons + +The Liturgy, the structure of Sacred Scripture, the documents of the Magisterium, Canon Law, the organizational structure of dioceses and parishes — these realities belong to the +universal Church. They are not the private data of any institution. They originate from the Church's universal authority and are shared across every diocese, parish, and Catholic +institution worldwide. + +This data is the natural subject of a data commons. The shared baseline — the General Roman Calendar, the canonical books of the Bible, the classification of Magisterial +documents, the directory of dioceses — can be defined, maintained, and served centrally. It is not merely a matter of defining standards that independent projects implement +locally; the data itself can be served from a shared commons, because it represents universal realities that belong to no local institution individually. + +Local adaptations exist within this tier: proper calendars for specific dioceses and religious orders, approved vernacular translations of Scripture and liturgical texts, diocesan +supplements to canonical structures. These adaptations fall under the governance of the local bishops' conference or diocese that published them, and many also fall under +copyright — which serves as a legitimate means of protecting both the authority of the local institution and the rights of the publisher charged by that institution with producing +the vernacular adaptation, to whom due compensation may be owed. + +The architecture must respect both jurisdiction and copyright. Centrally serving local adaptations does not require that copyrighted material be published as open source. A hybrid +model accommodates both realities: + +1. **Federated option.** The local institution serves its own adaptations locally, using CDCF standard schemas for interoperability. The data never leaves the institution's + infrastructure. This is always available as the default. +2. **Centralized option by agreement.** Following an agreement with the local institution, the CDCF serves the adaptation centrally while protecting the copyrighted data + according to any norms established by the rights holder — access controls, licensing terms, attribution requirements, or distribution restrictions as the local institution + sees fit. + +Both options operate on the same shared standards and schemas, so downstream software projects interoperate regardless of whether a given adaptation is served locally or +centrally. The distinction is operational (where the data is hosted and under what terms) rather than structural (how the data is represented). + +This distinction matters because it determines what the CDCF can and should build. For Tier 1 data, the CDCF sets validation standards for synthetic data generation. For Tier 2 +data, the CDCF defines interoperability standards. For Tier 3 data, the CDCF can go further: it can define the canonical standards, maintain the authoritative datasets, and serve +the shared baseline as operational infrastructure for the entire Catholic software ecosystem — with local adaptations served centrally where agreements permit, or federated where +they do not. + +--- + +## The CDCF Role Across Data Tiers + +The CDCF's bylaws charge it to "coordinate, develop, steward, and disseminate open-source software, data repositories, technical standards, and digital platforms," and its +manifesto describes a "builder commons" dedicated to aggregating, vetting, and communalizing resources for the Catholic Church's digital mission. The three-tier data model maps +directly onto that charter — with the CDCF's role escalating from standard-setting for sensitive data, through interoperability standards for local data, to operational data +stewardship for the shared patrimony of the universal Church. + +| Data Tier | CDCF Role | +| :----------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | +| **Tier 1: Sensitive institutional data** | Defines validation standards and certification criteria for synthetic data generation. Sets fidelity and privacy thresholds. Does not hold data. | +| **Tier 2: Local institutional data** | Defines interoperability standards and schema conventions. Does not hold data. | +| **Tier 3: Universal Church data** | Defines canonical standards, maintains authoritative datasets, and serves the shared baseline with contributed local adaptations. | + +For Tier 1, the CDCF contributes governance expertise: fidelity and privacy thresholds a synthetic dataset must meet for certification, what a synthetic data generation process +must demonstrate to receive CDCF certification (paralleling the project vetting criteria), and schema conventions that allow synthetic datasets from different institutions to be +combined or compared for cross-institutional research. Shared standards prevent each institution from solving the same problem independently. + +For Tier 2, the CDCF contributes interoperability standards: common schemas and conventions that allow locally governed systems to exchange data where needed, without requiring +those systems to pool their data or cede governance to a central authority. + +For Tier 3, the CDCF's contribution is qualitatively different. The Foundation is positioned not only to define the canonical identifiers and data representations for the +realities of Catholic life — liturgical celebrations, Scripture editions, Magisterial documents, canonical structures — but to maintain and serve those datasets as operational +infrastructure. The General Roman Calendar, for example, is not merely a standard to be implemented locally; it is a shared dataset that can be served centrally, with local proper +calendars contributed by the dioceses and religious orders that govern them. The same applies to a registry of Catholic Bible editions, a classification of Magisterial documents, +or a directory of dioceses and parishes. The CDCF can serve the universal baseline and, by agreement with the local institutions that govern them, incorporate and serve the local +adaptations — fulfilling its chartered role as steward of data repositories and creating a genuine data commons for the shared patrimony of the Church. + +--- + +## Relationship to the CDCF + +The research documented here supports both pillars of the CDCF's mission. + +**Project vetting.** Criterion 7 of the [CDCF Project Vetting Criteria](../project-governance/project-vetting-criteria.md) addresses data stewardship directly: a project that +handles data from Catholic institutions carries an obligation to those institutions and to the populations they serve, and the terms under which that data is used must be disclosed +and evaluated as part of the graduation review. Trusted synthetic data infrastructure is what makes responsible AI development possible at scale — an institution that deploys +validated synthetic data generation can develop AI tools for its own use and contribute to shared Catholic AI development without the legal exposure and governance burden that use +of real institutional data would require. + +**Standards program.** The [CDCF Standards program](../standards/overview.md) addresses the ecclesial data standardization challenge directly. By establishing shared canonical +identifiers for liturgical celebrations (CLEDR), Magisterial documents (CMDDR), Roman Missal editions (CRMETDR), and future standards for dioceses, Scripture editions, and +canonical structures, the standards program creates the authoritative digital vocabulary that Catholic software projects need. + +The three research memos (fragmentation, governance-as-code, and trusted data infrastructure) form an integrated argument. Fragmentation establishes why shared governance and +standards are urgent. Governance-as-code provides the enforcement architecture. Trusted data infrastructure provides the data foundation — both synthetic institutional data and +standardized ecclesial data — that allows Catholic institutions to develop technology worthy of that governance architecture. + +--- + +## Bibliography + +[^1]: + Catholic Health Association of the United States, _Catholic Health Care in the United States_ (Washington, DC: Catholic Health Association, 2024), + https://www.chausa.org/about/facts---statistics. + +[^2]: + CommonSpirit Health, _Audited Consolidated Financial Statements as of and for the Years Ended June 30, 2024 and 2023_ (Chicago: CommonSpirit Health, 2024), + https://www.commonspirit.org/content/dam/shared/en/pdfs/investor-resources/2024-CommonSpirit-Health-Annual-Report.SECURED.pdf. + +[^3]: + National Catholic Educational Association, _United States Catholic Elementary and Secondary Schools 2023–2024: The Annual Statistical Report on Schools, Enrollment and + Staffing_ (Arlington, VA: NCEA, 2024), https://www.ncea.org/NCEA/NCEA/Who_We_Are/About_Catholic_Schools/Catholic_School_Data/Catholic_School_Data.aspx. + +[^4]: + Catholic Charities USA, _Pathways Forward: 2024 Annual Report_ (Alexandria, VA: Catholic Charities USA, 2025), + https://www.catholiccharitiesusa.org/publications/2024-annual-report/. + +[^5]: + Paresh Dave, "Nvidia Reportedly Acquires Synthetic Data Startup Gretel," _TechCrunch_, March 19, 2025, + https://techcrunch.com/2025/03/19/nvidia-reportedly-acquires-synthetic-data-startup-gretel/. NVIDIA declined official comment; no corporate press release has been issued. + +[^6]: + U.S. Department of Veterans Affairs, Veterans Health Administration, "Synthetic Data to Improve Veteran Care," VA News, December 2020, + https://news.va.gov/81908/synthetic-data-improve-veteran-care/. + +[^7]: + United States Conference of Catholic Bishops, _Joint Letter on Artificial Intelligence Principles and Priorities_, June 9, 2025, + https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities. + +[^8]: + Latin American and Caribbean Episcopal Council (CELAM), _Inteligencia Artificial: Una mirada pastoral desde América Latina y el Caribe_ (Bogotá: CELAM, May 2025), + https://adn.celam.org/celam-presenta-documento-inedito-sobre-inteligencia-artificial-una-mirada-pastoral-desde-america-latina-y-el-caribe/. diff --git a/scripts/build-combined-pdf.sh b/scripts/build-combined-pdf.sh index 1b1343c..f344e0f 100755 --- a/scripts/build-combined-pdf.sh +++ b/scripts/build-combined-pdf.sh @@ -14,11 +14,10 @@ DOCS=( "project-governance/committees.md" "project-governance/project-types.md" "project-governance/definitions.md" - # AI Governance - "ai-governance/ai-vetting-criteria.md" - "ai-governance/fragmented-catholic-ai-governance.md" - "ai-governance/governance-as-code-catholic-ai.md" - "ai-governance/trusted-synthetic-data-ministry-ai.md" + # Research + "research/fragmented-catholic-digital-governance.md" + "research/governance-as-code-catholic-technology.md" + "research/trusted-data-infrastructure-catholic-ministry.md" # Standards "standards/overview.md" "standards/committees.md" @@ -35,7 +34,12 @@ for DOC in "${DOCS[@]}"; do # Page break between documents printf '\n\n
\n\n' >> "$COMBINED" fi - cat "$DOC" >> "$COMBINED" + # Namespace footnotes to avoid collisions between documents. + # Derives a prefix from the full path (e.g. "project-governance/committees" → "pgc") + # by taking the first letter of each hyphenated segment. + DOC_KEY="${DOC%.md}" + PREFIX=$(echo "$DOC_KEY" | tr '/' '-' | sed 's/\([a-z]\)[a-z]*/\1/g; s/-//g') + sed "s/\[\^\([^]]*\)\]/[^${PREFIX}-\1]/g" "$DOC" >> "$COMBINED" done echo "Building combined standalone HTML..." diff --git a/scripts/build-standalone-html.sh b/scripts/build-standalone-html.sh index 6933adb..cb12163 100755 --- a/scripts/build-standalone-html.sh +++ b/scripts/build-standalone-html.sh @@ -13,10 +13,9 @@ DOCS=( "project-governance/committees.md|committees|CDCF Governance Bodies" "project-governance/project-types.md|project-types|CDCF Project Types" "project-governance/definitions.md|definitions|CDCF Governance Definitions" - "ai-governance/ai-vetting-criteria.md|ai-vetting-criteria|AI Vetting Criteria" - "ai-governance/fragmented-catholic-ai-governance.md|fragmented-catholic-ai-governance|Fragmented Catholic AI Governance" - "ai-governance/governance-as-code-catholic-ai.md|governance-as-code-catholic-ai|Governance-as-Code for Catholic AI" - "ai-governance/trusted-synthetic-data-ministry-ai.md|trusted-synthetic-data-ministry-ai|Trusted Synthetic Data for Ministry AI" + "research/fragmented-catholic-digital-governance.md|fragmented-catholic-digital-governance|Fragmented Catholic Digital Governance" + "research/governance-as-code-catholic-technology.md|governance-as-code-catholic-technology|Governance-as-Code for Catholic Technology" + "research/trusted-data-infrastructure-catholic-ministry.md|trusted-data-infrastructure-catholic-ministry|Trusted Data Infrastructure for Catholic Ministry" "standards/overview.md|standards-overview|CDCF Standards Overview" "standards/committees.md|standards-committees|CDCF Standards Committees" ) @@ -31,11 +30,11 @@ for entry in "${DOCS[@]}"; do esac done NAV+='' -NAV+='
  • AI Governance