diff --git a/.github/ISSUE_TEMPLATE/ai-incident-report.md b/.github/ISSUE_TEMPLATE/ai-incident-report.md new file mode 100644 index 0000000..cae4548 --- /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", "JohnRDOrazio", "matthewa26"] +--- + +## 🛑 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. 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..75e628d --- /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", "JohnRDOrazio", "matthewa26"] +--- + +## 🏗️ 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**. 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 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. 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. 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). 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