Security

Church Gains uses a three-tier inference model designed to keep personally identifiable information as close to the source as possible.

Tier 1 (phone)runs Gemma 4 directly on the pastor's device. Paper forms are photographed and extracted locally. Names, phone numbers, and addresses never leave the building.

Tier 2 (browser) uses WebGPU to run a smaller Gemma variant in the browser tab. For churches that do not have the mobile app, extraction still happens client-side with no server round-trip.

Tier 3 (cloud) is reserved for complex reasoning tasks such as multi-step data queries and the AI Weekly Digest. Cloud calls are routed through the Vercel AI Gateway to providers that do not train on your data. PII from paper forms never reaches the cloud unless the pastor explicitly opts in for a specific form.

Every write to Planning Center is reviewed and approved by a staff member before it happens. The AI proposes; the human approves. No autonomous writes, ever.

Whether the action is importing a visitor card, creating a follow-up workflow, or updating a group roster, Church Gains presents the proposed change in a clear review screen. The pastor can edit any field, reject the proposal entirely, or approve and save. The Save button is the only path to Planning Center.

This guarantee is enforced in code: the AI tool schema includes a save capability, but the runtime dispatcher throws if the model attempts to call it autonomously. Saves can only happen via a dedicated API endpoint that is only invoked by the human-facing approval button.

Church Gains does not maintain a shadow copy of your church data. Planning Center is the only source of truth. Every read is a live API call to PC. Every write lands in PC so that existing reports, automations, and integrations keep working.

Cloud inference providers do not train on your data. Prompts are sent only to answer the request; providers may keep request logs for a limited period for abuse monitoring under their own policies.

If you cancel Church Gains, your data was never ours. The only data we persist is OAuth tokens (encrypted, scoped to your PC permissions), audit log entries (what the AI proposed and what you approved), and billing records.

Church Gains authenticates through Planning Center OAuth. We ride on each staff member's own PC permissions. There are no API keys, no service accounts, and no broad-access tokens.

If a user cannot see Giving in Planning Center, Church Gains cannot see Giving either. Permission boundaries are inherited directly from PC, not duplicated in our application.

OAuth tokens are stored in a per-user, per-organization row in a Postgres table. Refresh tokens are rotated on every use. The mobile app uses PKCE (Proof Key for Code Exchange) to protect against authorization code interception on deep links.

Every AI-proposed write is logged before it reaches Planning Center. Each audit record captures:

• Who proposed the change (which staff member)
• What was proposed (the full payload)
• Whether it was approved or denied
• What was saved to Planning Center (the final payload)
• Timestamp of every state transition

Pastors and organization admins can review the full trail at any time. Audit rows are insert-only and immutable. Postgres rules reject any UPDATE or DELETE on the audit table. Rows chain via a proposal ID so every step of a multi-phase action is traceable.

The inference architecture is designed to minimize cost and maximize privacy by pushing work as close to the user as possible.

Cloud inference is a fallback, not the long-term default. As on-device models improve, more tasks will migrate to Tier 1 and Tier 2 automatically.

Row-Level Security (RLS)in Postgres ensures that one church's data is invisible to another. Every query runs through policies that match the authenticated user's organization ID. There is no application-level “WHERE org_id =” that a developer could forget to add.

Service-role writes are restricted to server-side code paths. The service-role key is never exposed to client bundles, enforced at build time by the server-only import guard. A static analysis test in the test suite asserts that no client component imports or references the service-role key.