From 348a93b9df1ecb2cfcf22dd30dd1a6646026bbbf Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 10:37:25 -0400 Subject: [PATCH 1/9] Add CDCF Process and Two-Gate Framework sections Added a section about the CDCF process and the Two-Gate Framework to the README. --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/README.md b/README.md index 3352ac1..5a293a7 100644 --- a/README.md +++ b/README.md @@ -55,6 +55,17 @@ Supplementary research memos informing the design of the vetting criteria. | [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. | +--- +## The CDCF Process: A Bidirectional Commons + +The Catholic Digital Commons Foundation (CDCF) does not operate as a top-down gatekeeper. In alignment with our Manifesto, we steward a **Builder Commons** designed to aggregate, vet, and communalize open-source digital tools. + +Instead of a one-directional evaluation, projects enter a collaborative **Formation Pathway**. The CDCF actively accompanies creators by providing: +* **Rigorous Peer Review:** Technical assistance to refine architectures. +* **Shared Documentation:** Open playbooks to simplify compliance. +* **Canonical & Technical Guidance:** Mentorship to ensure tools are robust, secure, and faith-aligned. + +Rather than merely consuming commercial vendor tools, Catholic institutions are empowered as active builders, contributing local innovations upward so they can be communalized into global resources. --- ## The Two-Gate Framework From 3f4d09160669998de538c31368683f6b1db476cf Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 10:47:59 -0400 Subject: [PATCH 2/9] Update project vetting criteria with AI extensions Expanded project vetting criteria to include AI domain extensions and detailed requirements for algorithmic fairness, deployment governance, and security architecture. --- .../project-vetting-criteria.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/project-governance/project-vetting-criteria.md b/project-governance/project-vetting-criteria.md index 062127f..9ea0908 100644 --- a/project-governance/project-vetting-criteria.md +++ b/project-governance/project-vetting-criteria.md @@ -1,4 +1,13 @@ # CDCF Project Vetting Criteria +# Project Vetting Criteria & AI Domain Extensions + +> *"According to the grace of God given to me, like a wise master builder I laid a foundation, and another is building upon it."* — 1 Corinthians 3:10 + +## Purpose and Rationale +This framework serves as a formation standard, not a mechanism for exclusion. The eight criteria outlined below represent the benchmarks required for a project to be recognized as **commons-ready**. + +Passing a gate is a **formation milestone**, not a point of final judgment. If a project does not meet specific technical or ethical extensions (such as the Rome Call AI additions) upon initial review, the CDCF Technical Advisory Council (TAC) enters into active accompaniment with the project team to provide peer review, clear code examples, and remediation pathways. + | | | | :---------- | :------------------------------------------------------------------------------------------------------------------------------- | @@ -185,6 +194,10 @@ 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 5b: Impartiality & Algorithmic Fairness (AI Domain Extension — Gate 1) +* **Requirement:** Identify, document, and mitigate AI bias. +* **Developer Deliverables:** Data Bias Evaluation, Data Representativeness Analysis. +* **Gap Remediation:** Subgroup Testing Mitigation Plan option. --- ### Criterion 6: Deployment Governance Specification @@ -213,6 +226,10 @@ conditional-go, no-go, and defer**, each carrying distinct documentation require 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. +### Criterion 6b: Post-Deployment Reliability & Monitoring (AI Domain Extension — Gate 2) +* **Requirement:** Ensure dependability and graceful failure. +* **Developer Deliverables:** Monitoring Architecture, Data Drift Protocol, Kill-Switch Protocol. + --- ## Gate 2: Graduation to Active CDCF Project Status @@ -244,6 +261,10 @@ Data stewardship requirements are proportionate to the project's risk profile. P 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 7: Security Architecture & Data Boundaries (AI Domain Extension — Gate 1 Expansion) +* **Requirement:** Enforce data minimization and security. +* **Developer Deliverables:** Sanitization Report, Retrieval Poisoning Testing. + --- ### Criterion 8: Governance, Maintenance, and Subsidiarity Compatibility From 27af6edeeeac68458a3e6cf3f2df2c09078759b3 Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 10:56:01 -0400 Subject: [PATCH 3/9] Introduce Formation Pathway Philosophy section Added a section on the Formation Pathway Philosophy to explain the collaborative nature of project lifecycle stages and the support provided by the CDCF. --- project-governance/lifecycle.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/project-governance/lifecycle.md b/project-governance/lifecycle.md index 099f701..245bf71 100644 --- a/project-governance/lifecycle.md +++ b/project-governance/lifecycle.md @@ -5,6 +5,14 @@ alignment, technical excellence, and sustainable governance. --- +## The Formation Pathway Philosophy + +In accordance with the CDCF Manifesto, our lifecycle stages do not serve as an exclusionary corporate screening funnel. Instead, they represent an active **Formation Pathway** where the Technical Advisory Council (TAC) and the project team collaborate through mutual accompaniment. + +Each gate is a **Formation Milestone**. For every technical or ethical requirement a project must fulfill, the CDCF commits to reciprocal support: offering technical peer reviews, providing open-source compliance playbooks, and delivering canonical mentoring to help local innovations successfully mature into global resources. + +--- + ## 1. Proposal Phase Any community member or institution can propose a project for CDCF consideration. From 4b2fd78ffae11bfbfdebd39ffc24e680b988ed57 Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 11:30:37 -0400 Subject: [PATCH 4/9] Create AI Project Formation Intake issue template Added a new issue template for AI project formation intake, detailing project overview, governance acknowledgment, bias verification, security architecture, and next steps. --- .../ai-project-formation-intake.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/ai-project-formation-intake.md diff --git a/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md b/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md new file mode 100644 index 0000000..7ae02c4 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md @@ -0,0 +1,71 @@ +--- +name: "🚀 AI Project Formation Intake" +about: "Initiate the formation pathway for an open-source AI project or dataset." +title: "[AI INTAKE]: " +labels: ["formation-pathway", "ai-domain"] +assignees: ["mj3b"] +--- + +## 🏗️ Project Overview +* **Project Name:** +* **Lead Maintainer(s):** +* **Target Audience:** (e.g., Parishes, Dioceses, Catholic Schools, General Public) +* **Core AI Architecture:** (e.g., fine-tuned LLM, RAG system, traditional ML model) +* **Infrastructure Requirements:** (e.g., Cloud hosted, local on-premise parish server, API dependencies) + +--- + +## 🏛️ Shared Governance Lane Acknowledgment +*Please review and check the following boxes to acknowledge our open-source lane structure:* +- [ ] I understand that the **AI Governance Specialist** reviews this issue for technical risk, bias documentation, and privacy mitigation. +- [ ] I understand that the **Lead Developer & Technical Advisory Council** retain absolute authority over final system architecture, infrastructure safety, and repository code-merge approvals. +- [ ] I understand that if our system generates theological/catechetical outputs, it must undergo independent verification by the **Ecclesial Advisory Council** before Gate 2 graduation. + +--- + +## 🔬 Gate 1: Impartiality & Algorithmic Fairness Verification (Criterion 5b) +*AI tools within the Digital Commons must actively safeguard human dignity by identifying and mitigating systemic bias.* + +### 1. Data Bias Evaluation +*Provide a summary of the steps taken to evaluate your training datasets or prompt pipelines for historical, regional, or language bias:* +> + +### 2. Data Representativeness Analysis +*How does this model perform across demographically, linguistically, or regionally diverse Catholic populations?* +> + +### 3. Gap Remediation Plan (If Applicable) +*If your project currently lacks comprehensive subgroup testing data, outline your active mitigation plan for future development sprints:* +- [ ] *Check if applicable:* We request active accompaniment and technical peer review from the TAC to help build out our testing datasets. + +--- + +## 🛡️ Gate 1: Security Architecture & Data Boundaries (Criterion 7 Expansion) +*System design must enforce strict data minimization to protect the sanctity and privacy of the human person.* + +### 1. Training Data Sanitization Report +*Confirm and document that no personally identifiable information (PII), confidential parish records, or sacramental data are utilized to train or fine-tune this model:* +> + +### 2. Retrieval Poisoning Testing (Required for RAG Architecture) +*If your system utilizes Retrieval-Augmented Generation, detail the security protocols implemented to prevent malicious, secular, or non-canonical text injection into the vector database:* +> + +--- + +## 📉 Gate 2 Preview: Post-Deployment Reliability & Monitoring (Criterion 6b) +*While not fully required for initial incubation, please outline your architectural roadmap for long-term production safety:* + +* **Monitoring Architecture Statement:** How will you track runtime error logging and model failures in a production environment? + > +* **Data Drift Detection Protocol:** What is your protocol for flagging when model accuracy or theological output consistency degrades over time? + > +* **Kill-Switch Authority Protocol:** Name the human role or automated threshold authorized to safely take the AI system offline if severe hallucinations or security exploits occur. + > + +--- + +## 🏁 Next Steps +Once submitted: +1. The **AI Governance Specialist** (`@mj3b`) will review your deliverables and open a collaborative dialogue thread inside this issue. +2. If gaps are identified, we will collaboratively design a **remediation pathway** to ensure your project successfully achieves its first **Formation Milestone**. From e554fdf341bc5bad348dce543e648925d5eebc2e Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 11:40:31 -0400 Subject: [PATCH 5/9] Create AI Incident & Anomaly Report template Added a template for reporting AI incidents and anomalies, including sections for critical notices, incident context, classification, reproduction steps, supporting evidence, and automated triage lifecycle. --- .github/ISSUE_TEMPLATE/ai-incident-report.md | 59 ++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/ai-incident-report.md diff --git a/.github/ISSUE_TEMPLATE/ai-incident-report.md b/.github/ISSUE_TEMPLATE/ai-incident-report.md new file mode 100644 index 0000000..5f752d9 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/ai-incident-report.md @@ -0,0 +1,59 @@ +--- +name: "🚨 AI Incident & Anomaly Report" +about: "Report a behavioral deviation, doctrinal error, or data breach in an active CDCF AI tool." +title: "[AI INCIDENT]: - " +labels: ["incident-response", "triage-pending"] +assignees: ["mj3b"] +--- + +## 🛑 Critical Notice +*If this incident involves an active data breach leaking personal data or sacramental records, please check the emergency box below to fast-track immediate server isolation by the Technical Advisory Council.* +- [ ] **EMERGENCY:** This incident involves live data exposure or a critical infrastructure exploit. + +--- + +## 📱 Incident Context +* **Target AI Tool/System Name:** +* **Deploying Institution:** (e.g., Archdiocese of X, Parish of Y, School of Z) +* **Date/Time of Detection:** +* **Environment:** (e.g., Public web app, internal parish database, WhatsApp bot) + +--- + +## 🔍 Incident Classification +*Select the classification category that best describes the observed system failure mode:* + +### [] Category A: Catechetical / Doctrinal Deviation +*The system generated outputs that distort authoritative Church teaching, misrepresent dogmatic principles, or approach Criterion 1 boundaries (such as attempting sacramental simulation or claiming clerical identity).* + +### [] Category B: Algorithmic Bias & Harm +*The system produced discriminatory, unrepresentative, or asymmetric outputs that disproportionately impact vulnerable populations (e.g., families, ethnic groups, low-bandwidth dioceses).* + +### [] Category C: Technical Failure & Security Exploit +*The system suffered an infrastructure crash, an API data leak, model poisoning, or severe hallucinations causing operational downtime.* + +--- + +## 📝 Step-by-Step Reproduction Ledger +*Provide the exact prompt inputs and system behaviors required to reproduce the quality defect. Treating this like a standard software bug report ensures engineers can isolate the root cause.* + +1. **System Prompt / User Input Sent:** + > +2. **Observed System Output / Behavior Received:** + > +3. **Expected Standard Behavior:** + > + +--- + +## 🖼️ Supporting Evidence & Lineage +*Attach any relevant system logs, JSON API payloads, or user screenshots demonstrating the failure mode:* +> + +--- + +## 🏁 Automated Triage Lifecycle +*Upon clicking submit, this report enters an emergency evaluation loop:* +1. **The AI Governance Specialist** (`@mj3b`) performs an initial assessment within 72 hours to verify a material behavioral deviation. +2. **Technical incidents** are routed to the **TAC** for architecture containment. +3. **Doctrinal deviations** are routed to the **Ecclesial Advisory Council** to evaluate safety risks. From a676843f182220bc7822618ac1634015793c1e78 Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 11:43:31 -0400 Subject: [PATCH 6/9] Add AI Incident Response Protocol document This document outlines the AI Incident Response Protocol for handling behavioral deviations, data breaches, and theological errors in AI systems. It details the operational phases from detection to transparent communication. --- project-governance/incident-response.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 project-governance/incident-response.md diff --git a/project-governance/incident-response.md b/project-governance/incident-response.md new file mode 100644 index 0000000..f4dc9c3 --- /dev/null +++ b/project-governance/incident-response.md @@ -0,0 +1,25 @@ +# AI Incident Response Protocol + +## 1. Purpose and Scope +This document defines the procedure for handling behavioral deviations, data breaches, or theological errors produced by live, active AI systems within the Catholic Digital Commons. This protocol ensures continuous quality assurance, protects user privacy, and preserves the integrity of Church teaching. + +## 2. Operational Incident Phases + +### Phase 1: Detection & Intake +* **Mechanism:** Incidents are logged via the standardized `ai-incident-report.md` issue tracker. +* **Fast-Track:** Incidents flagged as a critical infrastructure exploit or a live data leak bypass the standard timeline for immediate containment. + +### Phase 2: Joint Advisory Assessment +Upon submission, an initial evaluation is completed within 72 hours to verify a material behavioral deviation. Responsibility lanes are unbundled by domain expertise: +* **Technical Anomalies & Privacy Breaches:** Assessed by the AI Governance Specialist and the Technical Advisory Council (TAC) for system architecture isolation. +* **Catechetical & Doctrinal Deviations:** Assessed by the Ecclesial Advisory Council (EAC) to evaluate proximity to Criterion 1 boundaries. + +### Phase 3: Response & Status Mitigation +Based on the joint risk assessment, the Board of Directors executes one of three outcomes: +1. **Maintained Status:** System remains Active with documented developer mitigation. +2. **Suspended Status:** System status in `lifecycle.md` is reverted back to "Incubating" or "Experimental" pending a formal re-vetting cycle. +3. **Revoked Status:** Endorsement is removed from the Commons database with a documented public rationale. + +### Phase 4: Transparent Communication +* **Registry:** The foundation maintains a public ledger tracking verified system anomalies. +* **Notification:** A standardized protocol ensures that any parish, diocese, or institution deploying the affected tool is immediately notified of the nature of the failure and the recommended local containment steps. From 77f1e3467b3f239568c064f373d40494e1f4466f Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Mon, 29 Jun 2026 12:16:04 -0400 Subject: [PATCH 7/9] Create magisterial monitoring protocol document This document outlines the monitoring and lifecycle protocol for Magisterial sources, detailing roles, review triggers, and update procedures. --- .../magisterial-monitoring-protocol.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 project-governance/magisterial-monitoring-protocol.md diff --git a/project-governance/magisterial-monitoring-protocol.md b/project-governance/magisterial-monitoring-protocol.md new file mode 100644 index 0000000..ba17b96 --- /dev/null +++ b/project-governance/magisterial-monitoring-protocol.md @@ -0,0 +1,21 @@ +# Magisterial Sources Monitoring & Lifecycle Protocol + +## 1. Purpose and Scope +The CDCF Project Vetting Criteria relies on a foundational "Magisterial Grounding" table to justify technical risk parameters based on Catholic Social Teaching and Ecclesial guidance. Because modern guidance on Artificial Intelligence is expanding rapidly, this protocol establishes a systematic pipeline for monitoring, evaluating, and updating our baseline compliance references. + +## 2. Monitoring Roles & Jurisdictions +To prevent data drift in our moral and canonical benchmarks, monitoring responsibilities are divided by regional and academic focus: +* **Primary Academic Monitor (Fr. Michael Baggot - EAC):** Responsible for reviewing global Vatican declarations, Pontifical Academy statements, and academic theological research within 30 days of official publication. +* **European Ecclesial Monitor (Fr. Charbel Bteich - EAC):** Responsible for tracking AI regulatory guidelines, pastoral letters, and institutional decrees emerging from the Council of European Bishops' Conferences (CCEE) and regional European dioceses. +* **Technical Implementation Authority (Lead Developer / TAC):** Responsible for officially publishing approved table updates to the repository architecture. + +## 3. Trigger Thresholds for Criteria Review +A formal review cycle of the `project-vetting-criteria.md` file is automatically triggered within 60 days if a newly issued Magisterial document meets any of the following conditions: +1. **Structural Shifts:** Establishes a new ecclesial regulatory body or monitoring commission (e.g., the Vatican City State AI Commission). +2. **Boundary Modification:** Alters or clarifies red-line ethical boundaries concerning human dignity, sacramental simulation, or ministerial identity. +3. **Data Directives:** Introduces updated mandates regarding data privacy, archival custody, or the management of parish/diocesan digital assets. + +## 4. Operational Update Procedure +1. **Proposal:** The Ecclesial Advisory Council (EAC) drafts a formal amendment to the Magisterial Grounding table following a verified monitoring trigger. +2. **Approval:** The Board of Directors conducts a standard voice vote to ratify the amendment. +3. **Deployment:** The AI Governance Specialist or Lead Developer updates the markdown array and tags the commit with the updated version milestone (e.g., v0.3). From 639333ed3fab133700760ef138254a648419713a Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Wed, 1 Jul 2026 17:00:05 -0400 Subject: [PATCH 8/9] Add additional assignees to AI project intake template Added Fr. John and Matthew to the intake to help expand further. --- .github/ISSUE_TEMPLATE/ai-project-formation-intake.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md b/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md index 7ae02c4..75e628d 100644 --- a/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md +++ b/.github/ISSUE_TEMPLATE/ai-project-formation-intake.md @@ -3,7 +3,7 @@ name: "🚀 AI Project Formation Intake" about: "Initiate the formation pathway for an open-source AI project or dataset." title: "[AI INTAKE]: " labels: ["formation-pathway", "ai-domain"] -assignees: ["mj3b"] +assignees: ["mj3b", "JohnRDOrazio", "matthewa26"] --- ## 🏗️ Project Overview From e4f22df548ea9c4c35ed689ead4ca99f6104479f Mon Sep 17 00:00:00 2001 From: markjuliusbanasihan <90214617+mj3b@users.noreply.github.com> Date: Wed, 1 Jul 2026 17:01:13 -0400 Subject: [PATCH 9/9] Update assignees in AI incident report template Added additional assignees for AI incident reports. --- .github/ISSUE_TEMPLATE/ai-incident-report.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/ai-incident-report.md b/.github/ISSUE_TEMPLATE/ai-incident-report.md index 5f752d9..cae4548 100644 --- a/.github/ISSUE_TEMPLATE/ai-incident-report.md +++ b/.github/ISSUE_TEMPLATE/ai-incident-report.md @@ -3,7 +3,7 @@ name: "🚨 AI Incident & Anomaly Report" about: "Report a behavioral deviation, doctrinal error, or data breach in an active CDCF AI tool." title: "[AI INCIDENT]: - " labels: ["incident-response", "triage-pending"] -assignees: ["mj3b"] +assignees: ["mj3b", "JohnRDOrazio", "matthewa26"] --- ## 🛑 Critical Notice