Appearance
Failure Modes v2.6
Last updated: March 25, 2026
Most vendors hide how their systems fail. We lead with it. Understanding failure behavior is more useful than understanding success behavior — because failures are where trust is actually tested.
Design Principle: Suppress Over Guess
AI4Love is designed to produce no output rather than incorrect output. This is the core failure behavior across every layer:
- If an agent cannot determine a pattern with confidence, it does not generate an insight.
- If the LLM returns text that doesn't match the expected pattern type, the insight is discarded.
- If a data sync encounters records that can't be matched to a supporter by email, those records are skipped — not force-matched.
Silence is safer than noise. A missing insight costs nothing. A wrong insight erodes trust.
Agent Failure Behavior
| Scenario | System Response |
|---|---|
| Agent can't reach Airtable | Agent run fails. No insights written. Error logged. Next nightly run retries. |
| Agent can't reach Claude API | Pattern detection completes (it's math), but text generation is skipped. Insight is queued without a headline for the next run. |
| Supporter has insufficient data | Eligibility filters suppress the insight. Minimum activity thresholds prevent low-confidence recommendations. |
| LLM returns malformed text | Validation rejects the response. Insight is not saved. Error is logged. |
| Duplicate insight detected | Deduplication logic prevents the same pattern from being surfaced repeatedly for the same supporter within a configurable window. |
No Hallucinated Insights
The LLM does not decide what to surface. Deterministic rules identify the pattern first. The LLM only writes the text after the pattern is confirmed. If the pattern detection layer finds nothing, the LLM is never called.
This means AI4Love cannot "hallucinate" an at-risk supporter or fabricate a donation trend. The math either supports the pattern or it doesn't.
Integration Failure Behavior
| Scenario | System Response |
|---|---|
| OAuth token expired | Nango automatically refreshes. If refresh fails, sync is paused and the integration shows "disconnected" in the dashboard. No partial writes. |
| Source API rate limited | Exponential backoff with max 3 retries. If all retries fail, sync stops and reports the error. No data is lost — the next sync picks up where it left off. |
| Email doesn't match existing supporter | For Blackbaud/Mailchimp syncs: a minimal People record is created (email only). No data is attributed to the wrong person. |
| Airtable API unavailable | All write operations fail atomically. No partial record creation. Dashboard shows cached data until the API recovers. |
| Environics returns no data for postal code | Enrichment is skipped for that supporter. No placeholder or guessed values are written. |
MCP Failure Behavior
| Scenario | System Response |
|---|---|
| Invalid access key | Request rejected immediately. No data returned. Event logged. |
| Rate limit exceeded | HTTP 429 returned. No data leaked in error response. |
| Daily retrieval cap hit | Subsequent queries return a clear error message. Resets on 24-hour rolling window. |
| Airtable unavailable during MCP query | Error returned to the AI assistant. No cached or stale data served as a fallback. |
| LLM provider unavailable | MCP server continues to respond (it doesn't depend on the LLM). The AI assistant may not be able to process the response, but the MCP server's behavior is unchanged. |
Dashboard Failure Behavior
| Scenario | System Response |
|---|---|
| Backend API unavailable | Dashboard shows loading states, then error messages. No stale data presented as current. |
| User session expired | Automatic redirect to login. No cached session reuse. |
| Airtable returns partial data | Dashboard renders what it has. Missing sections show clear empty states, not zeros or placeholders. |
Incident Response
In the event of a security incident affecting your organization's data:
| Phase | Action | Timeline |
|---|---|---|
| Detection | Automated monitoring of error rates, auth failures, and anomalous access patterns via Vercel and Doppler logs. | Continuous |
| Containment | Revoke affected credentials, disable compromised integrations, isolate affected org scope. | Within 4 hours of detection |
| Notification | Notify affected organization's designated security contact with incident summary, scope, and affected data categories. | Within 72 hours of confirmed breach involving customer data |
| Investigation | Root cause analysis, review of audit logs, assessment of data exposure scope. | Within 7 days |
| Remediation | Credential rotation, configuration hardening, process update. Post-incident report provided to affected organization. | Within 14 days |
AI4Love will cooperate fully with your organization's own incident response procedures and any regulatory notification requirements.
Recovery Guarantees
| Component | Recovery Path |
|---|---|
| Supporter data | Lives in Airtable. Airtable provides platform-level redundancy. AI4Love does not maintain separate backups (Zero-Custody). Your organization controls backup and restore. |
| Insights | Stored in Airtable. If lost, agents regenerate them on the next nightly run. No manual intervention needed. |
| OAuth connections | Re-established by staff through the Integrations dashboard. No AI4Love intervention required. |
| Application state | Stateless. Vercel redeploys from git. No persistent state to corrupt or lose. |