Architectural Blueprint And Strategic Implementation For The Who Cares Wizard On 2Ia - Source Excerpt 04 - Escalation paths and thresholds

Back to Architectural Blueprint And Strategic Implementation For The Who Cares Wizard On 2Ia

Summary

This source excerpt begins near Escalation paths and thresholds and preserves the surrounding evidence from 2IA.org/agent-file-handoff/Archive/2026-05-17-who-cares-wizard/Architectural Blueprint and Strategic Implementation for the Who Cares Wizard on 2ia.org.md.

**Source path:** 2IA.org/agent-file-handoff/Archive/2026-05-17-who-cares-wizard/Architectural Blueprint and Strategic Implementation for the Who Cares Wizard on 2ia.org.md

### Escalation paths and thresholds

Escalation should be explicit and deterministic.

| Priority level | Typical trigger | Maximum extra questions before route | Escalation action |
|---|---|---|---|
| Critical | Immediate threat to life, bodily autonomy, or child safety | 0–1 | Emergency interrupt; present local emergency and crisis options first |
| Urgent | No shelter tonight, utility cutoff within 48 hours, medication or care gap within 72 hours, exploitation or active stalking risk | 1–2 | Same-day live support or urgent service finder |
| Time-sensitive | Known filing deadline, hearing date, appeal window, benefit termination, court appearance, inspection request | 2–3 | Collect only deadline-critical facts and route to official complaint or legal aid |
| Standard | Harm without immediate danger or deadline | 3–5 | Normal branch flow and ranked resource results |
| Informational | User mainly wants to understand options or learn who handles an issue | 2–4 | Short educational summary plus official resources |

The system should always allow a **manual escalation** path: “This doesn’t fit — show me a human or a broader list.” That matters because many real grievances are multi-system problems. A person may simultaneously face housing loss, disability accommodation barriers, caregiver strain, and debt. In such cases, the product should show a **composite result** rather than force one label.

## Privacy, security, and consent

### Privacy model

The privacy baseline should be **anonymous use by default, opt-in sharing by exception**. NIST’s Privacy Framework is a strong foundation because it explicitly organizes privacy work around governance, control, communication, and protection, and it treats **data minimization** and privacy-risk assessment as core operational concerns. citeturn12view0turn12view1turn12view2turn12view3

That has concrete product consequences. The wizard should not require account creation for basic routing. It should not ask for exact street address until a local service search genuinely requires it. It should avoid mandatory free-text narratives at the top of the flow. It should store only enough data to return results, provide opt-in save/resume where justified, and make deletion simple.

It is also important to describe the privacy regime **accurately**. HHS explains that HIPAA applies to covered entities and business associates, not every website or app, and the FTC stresses that many health apps are not covered by HIPAA even though health-breach rules may still apply. So the wizard should **not market itself as “HIPAA compliant” unless that is actually true for the relevant deployment and data flows**. citeturn18search12turn18search17turn18search18

If the product intentionally collects information from children under 13, or has actual knowledge that it is doing so, COPPA duties become relevant, including parental notice and consent obligations, reasonable security, and limits on collecting more information than is necessary. Even if the wizard is not child-directed, youth-safe design still matters because family and child-welfare grievances are in scope. citeturn19search0turn19search5turn19search3

### Suggested user metadata to collect

| Field | Why collect it | When to ask | Sensitivity guidance |
|---|---|---|---|
| Urgency level | Decides interrupt vs ordinary flow | First screen | High value, low invasiveness |
| Who is affected | Distinguishes self, another person, child, household, or community | Early | Low sensitivity |
| Country | Needed for official legal and service routing | Early when rights or service localization matters | Moderate |
| State/province/territory | Needed for state-level agencies and deadlines | Conditional | Moderate |
| City/postal code | Needed for shelter, local offices, and nearby services | Later; optional until necessary | Higher sensitivity |
| Incident date or deadline date | Needed for enforcement, appeal, and cutoff logic | As soon as a deadline-based route is likely | Moderate |
| Legal or immigration status | Sometimes essential for routing; always optional with “prefer not to say” | Only on relevant branches | High sensitivity |
| Age band and whether a minor is involved | Needed for crisis, child-protection, and consent rules | Early on family/youth branches | High sensitivity |
| Accessibility needs | Needed to route by ASL, TTY, mobility, reading support, cognitive load, screen reader | Early and always optional | Sensitive but necessary for equity |
| Language and script preference | Needed for localized results and communication channels | Early | Low to moderate |
| Safe contact method | Call, text, chat, email, no follow-up | Before presenting routable actions | High sensitivity |
| Need for anonymity | Governs whether save/share features appear | Early | Low sensitivity |
| Short optional summary | Helps handoff when the user chooses to share | End of flow, never mandatory | Highest sensitivity in practice |

For high-risk categories, the product should default to **structured choices rather than open narrative**. That reduces accidental oversharing and keeps the routing process more legible.

### Safety, device privacy, and consent wording

For abuse and stalking contexts, device safety is part of product safety. The National Domestic Violence Hotline publishes technology-safety guidance, including clearing search history and thinking through online abuse, and encourages survivors to consider whether their internet use may be monitored. That strongly supports a **quick-exit button**, discreet page titles, and a “don’t save my answers” mode. citeturn24search0turn24search1turn24search3turn24search21

A plain-language consent pattern should look like this:

> **Before we continue:** You can use this tool anonymously. We ask only for the details needed to show the most relevant help and information. Your answers will **not** be sent to another organization unless you choose to share them. If someone is in immediate danger, leave this tool and contact local emergency services now. By selecting **Continue**, you consent to the temporary processing of your answers to generate results.

For any handoff, the product should require **field-by-field review**:

> **Share this summary?** We will send only the fields shown below to **[organization name]**: issue category, urgency, city/region, language, accessibility needs, preferred contact method, and your optional summary. You can remove any field before sending.

### Security and trust requirements

At minimum, the deployment should include encrypted transport, secret management, least-privilege admin roles, tamper-evident audit logs for content changes, security testing aligned with OWASP ASVS, and monitoring for confusable or spoofed domains relevant to 2ia.org. Unicode and ICANN’s guidance make the spoofing risk real; OWASP ASVS makes verification repeatable. citeturn11view3turn2search1turn11view4

## Implementation, accessibility, localization, and metrics

### Web and mobile integration notes

For product reach and maintenance, I recommend a **responsive web app first**, optionally installable as a PWA later. That avoids duplicating the same highly sensitive decision logic across separate native codebases, while still allowing excellent mobile performance.

The UX design should adopt the following patterns as default product rules: