CareLink

CareLink turns fragmented survivor services into one shared recovery plan, helping survivors control what gets shared while social workers and agencies coordinate around recovery goals.

Comment

Inspiration

As a social worker student, I've sat across from survivors of exploitation in intake rooms, in borrowed conference spaces at nonprofit partners, and in school hallways doubling as offices. One pattern repeats itself with painful regularity: before a survivor can receive any help, they are asked to tell their story again.

Again to the housing provider. Again to the workforce program. Again to legal aid. Again at the benefits office.

Each retelling is not just logistically exhausting. For survivors of exploitation, repeated disclosure can be retraumatizing. A system designed to help can end up requiring harm as a condition of entry. And despite all that repetition, the agencies still don't coordinate. A legal aid provider may not know the housing situation is unstable. A workforce program may not know that missing ID documents are the actual blocker. The survivor carries the full picture in their head while the support system fragments around them.

I've also watched what happens when AI tools enter this space without care. Generic job matching algorithms undervalue caregiving experience. Formal work history requirements penalize survivors who spent years in controlled or coerced labor. Well-meaning automation can replicate exactly the structural exclusion a survivor is trying to escape.

CareLink started with a reframe: the referral is not the unit of care. The survivor's goal is.

Most closed-loop referral platforms ask: Did this referral get sent, accepted, or closed? CareLink asks: Did this action move the survivor closer to a safe, realistic economic recovery goal?

How I Built It

CareLink is organized around a six-layer privacy architecture that separates sensitive survivor data from AI-assisted planning at every step.

The Core Flow

Protected Intake Vault
  → Local Privacy Filter
    → Human Review
        → AI Goal & Pathway Assistant
          → Survivor / Social Worker Approval
            → Goal-Based Agency Coordination

Layer 1: Protected Intake Vault. Raw intake, including narratives, documents, and contact preferences, stays in an encrypted vault. AI has no default access.

Layer 2: Local Privacy Filter. Before any AI-facing processing, direct identifiers are masked in the browser:

"My name is Jane Doe. I live at 123 Main Street."
→ "My name is [NAME]. I live at [ADDRESS]."

Layer 3: AI Goal & Pathway Assistant. The AI receives the de-identified intake and generates draft goal cards, pathway options, skill maps, missing information flags, and confidence levels. It does not make decisions. It produces options.

Layer 4: Human Decision & Survivor Choice. Every AI output is reviewed. The survivor and social worker decide together which goals feel realistic, which agencies should be involved, and what information each one can see.

Layer 5: Goal-Based Agency Coordination. Partner agencies receive only the information relevant to their specific role within a specific goal. The access rule is strict:

$$\text{Agency}_i \text{ can view field } f \iff \exists\ \text{consent}(i,\ \text{goal},\ f)\ \text{with status} \in {\texttt{approved},\ \texttt{limited}}$$

Information shared with any agency is always a strict subset of the approved abstraction, which is itself a strict subset of the protected vault:

$$\text{Agency}_i\ \text{View} \;\subseteq\; \text{Approved Abstraction} \;\subseteq\; \text{Protected Intake Vault}$$

This relationship is not just a design principle. It is enforced in the data model, the API layer, and the UI.

Tech Stack

  • Frontend: Next.js, React, Tailwind CSS
  • Backend: Supabase (auth, Postgres, storage)
  • AI: Anthropic API, receiving only approved abstraction
  • Deployment: Vercel
  • Demo data: Fully synthetic survivor profiles throughout

Challenges

The hardest design problem was not the AI. It was the architecture of trust.

Deciding what the AI should never see turned out to be more consequential than deciding what it should generate. That meant building human checkpoints as structural requirements, not UI suggestions. The AI pathway generator cannot run unless a case abstraction has been human-approved. Referral channels cannot open without explicit survivor consent by agency and data category. These constraints are not guardrails layered on after the fact. They are the core data model.

A second challenge was representing informal labor fairly. Survivors of exploitation often have years of unpaid caregiving, survival labor, or coerced work that standard workforce tools discard. The skill mapping layer had to extract value from descriptions like "cared for siblings," "translated for relatives," and "helped with a family business," not just job titles and W-2 history. Building for that required rethinking what counts as a credential.

The third challenge was the survivor interface. Building a plain-language recovery plan that a person under significant stress could actually read and act on meant stripping out nearly every piece of case management jargon. The survivor does not see intake records, referral channels, or privacy filter runs. They see: what is happening, who is helping, what is waiting, and what needs my input.

Finally, the hardest discipline was resisting the temptation to automate decisions that belong to humans. The system is designed to reduce the cognitive burden of coordination, not to replace clinical judgment. Every pathway the AI generates is labeled a draft. Every referral requires a human decision. Survivors can reject, revise, or restrict at any point in the process.

What I Learned

We learned that responsible AI design in social services is fundamentally a problem of information architecture. The question is not how powerful should the model be? It is: what is the minimum information the model needs, and who controls access to everything else?

We also learned that the most important feature in a platform serving survivors is often the absence of a feature. No automatic referrals. No required disclosures. No AI decisions without review. No data sharing without explicit, revocable, category-specific consent.

Building CareLink deepened something I already believed from clinical practice: tools designed for vulnerable populations have to be built with the same ethical rigor we expect from direct service. The intake is not a dataset. The narrative is not a prompt. The survivor is not a case to be optimized. They are the author of their own recovery plan.

The system exists to make that authorship possible.

Built With

Share this project:

Updates