Guardian AI¶
A founding design principle and long-term capability roadmap.
Validation status: [HYPOTHESIS] — the four pillars are design commitments. The capabilities below are intended behaviours, not implemented or tested features. Claims about protective outcomes (reduced exploitation, improved service navigation) are untested theories.
Vision¶
MPowerUP's users — people navigating recovery, reentry, houselessness, and poverty — are disproportionately targeted by exploitative tech, algorithmic discrimination, and digital complexity. Confusing ToS agreements, predatory offers inside messaging apps, opaque government benefit systems, and scam networks all extract value from people who can least afford to lose it.
The Guardian AI is MPowerUP's answer: an AI agent designed not to monetise users, but to protect them. It acts as a personal advocate — translating complexity into plain language, flagging threats before they land, and navigating the bureaucratic maze on the user's behalf. It is not a chatbot; it is a protective tool in the user's pocket.
Assumptions we're betting on¶
These assumptions are load-bearing. If any is wrong, the Guardian AI as specified fails — not just adjusts.
| Assumption | Status | What would falsify it |
|---|---|---|
| Users will invoke the agent (consent-first means passive protection doesn't exist) | [HYPOTHESIS] |
Pilot shows < 20% of users ever tap "Ask Guardian" in a real-stress scenario |
| Plain-language translation at 6th-grade level is sufficient for the target population | [HYPOTHESIS] |
User testing shows participants still misunderstand key benefit/legal content after translation |
| Scam detection can identify threats without false positives that flag legitimate offers | [HYPOTHESIS] |
No heuristics defined yet; no test dataset from this population exists |
| Ollama runs acceptably on budget Android ($50–150) with partial connectivity | [HYPOTHESIS] |
Benchmark testing; not yet performed on target hardware |
| The Guardian AI increases trust in MPowerUP rather than creating dependency or anxiety | [HYPOTHESIS] |
Qualitative user research with pilot participants |
Four pillars¶
These principles govern every Guardian AI design decision — and inform the broader product, even before the AI layer exists.
| Pillar | What it means |
|---|---|
| Consent-first | The user invites the agent. It never runs passively, never reports back to third parties, never initiates a conversation without a prompt. |
| Offline-resilient | Works on budget Android with partial connectivity. On-device inference preferred; cloud fallback only when explicitly accepted. |
| Privacy-preserving | No surveillance. Data stays on-device or within the user's Circle. The guardian never becomes a data-collection tool. |
| Plain-language | Every output written at a 6th-grade reading level. No jargon. Concrete next steps, not abstract summaries. |
Capabilities¶
| Capability | What it does |
|---|---|
| Plain-language translator | Converts benefits letters, legal notices, app ToS, and government forms into plain English with actionable next steps |
| Scam detector | Flags suspicious messages, links, and requests inside Circles before the user acts on them |
| Service navigator | Finds shelter beds, food banks, legal aid, and medical clinics within the user's area — tonight, not in theory |
| Digital literacy tutor | Explains what app permissions, data requests, and consent dialogs actually mean before the user agrees |
Phased implementation¶
The Guardian AI is a founding principle, not a Day 1 feature. The philosophy shapes every design decision now; the live agent deploys when MPowerUP has real users and real data to learn from.
| Phase | Milestone | Guardian AI work |
|---|---|---|
| Phase 1–3 | Core app, hardening | Design language locked in — consent-first, offline-resilient, privacy-preserving applied to all non-AI features |
| Phase 4.5 | Guardian AI v1 | First live agent: Claude API (cloud) + Ollama offline fallback. Plain-language translator + scam detector inside Circles |
| Phase 5+ | Guardian AI v2 | On-device inference, MCP tool integrations (government portals, service APIs), multi-step agentic workflows |
Technical approach¶
Phase 4.5 — cloud-first with offline fallback¶
- Claude API (Anthropic) — primary inference for plain-language translation, scam detection, service navigation.
- Ollama — local model fallback for offline or low-connectivity scenarios (same pattern as RlivN).
- The user controls which backend is active; default is on-device when available.
Phase 5+ — on-device and agentic¶
- On-device small model (quantized, ARM-optimized) for core capabilities with no data leaving the device.
- Model Context Protocol (MCP) tools for multi-step workflows: filling benefit applications, querying government service APIs, navigating portals on the user's behalf.
What Guardian AI is NOT¶
- Not a general-purpose chatbot.
- Not a data-collection layer.
- Not a replacement for human facilitators inside Circles.
- Not a feature gated behind a paid tier.
Why this matters for grant strategy¶
Documenting the Guardian AI as a founding principle now — even before implementation — strengthens MPowerUP's position with mission-aligned funders (e.g. NLnet / NGI Zero Commons Fund for privacy-preserving consent-first AI; Mozilla's protective-AI focus; reentry-focused programs for whom a scam detector and service navigator are direct outcomes). Per the Epistemic Honesty directive, applications must label these as intentional design, not validated results.
Known unknowns¶
Not blocking Phase 1–3, but must be resolved before Phase 4.5 development begins.
- Scam detection heuristics: What signals define a "scam" inside a Circle? Who updates the model when new scam patterns emerge?
- Facilitator conflict: What happens when the Guardian AI flags a message from a Circle facilitator? Does the user trust the agent or the facilitator? No design decision exists.
- Offline model size/performance: Which Ollama model, at what quantization, runs within the memory and battery constraints of a budget Android device?
- Integration point in UX: How does the user invoke the agent? No UX spec exists.
- Service data accuracy: The service navigator depends on OpenStreetMap/Overpass data. Shelter beds and food-bank hours change daily. How stale is "too stale" for a person who is hungry tonight?
- The automation-bias trap: Georgetown CSET (2024) documents that automated safety tools cause users to treat silence (no flag) as a safety clearance — and high system accuracy increases this effect. A user who has seen Guardian AI flag external threats correctly will develop a heuristic that facilitator silence means safety — exactly wrong for insider threats. The UX must explicitly communicate what Guardian AI does not watch for, at equal prominence to what it does. A facilitator report mechanism is the primary safety layer for insider threats; Guardian AI cannot substitute for it.
Cross-cutting design question (still open): the documented risk areas — benefit-cliff harm, automation bias, facilitator predation, P2P delivery failure — concentrate harm on the same users at the same moments: highest cognitive load, highest trust in the system, lowest ability to recognise or recover from harm. This is a compounding profile, not five independent risks. The unanswered design question:
What does MPowerUP look like if it is designed specifically to fail gracefully under cognitive overload, rather than assuming users will engage protective mechanisms correctly under stress?