TRACE

• 

  Guided walkthrough opens from one link. No sign-in, no form. Seven steps through a protection officer's working day.

• 

  Caseload triaged by urgency. Transfer and flag are one tap from the list, not buried three screens deep.

• 

  Intake in the language the conversation actually happened in, mapped to IOM Human Trafficking Case Data Standard fields.

• 

  A case-grounded assistant. Ask why something was flagged and get an answer traceable to the record, not a black box.

• 

  Cluster reporting drafted from the caseload, so the record a caseworker already made becomes their coordinator's report.

• 

  The same build at 390px. Mobile-first because the field device is a phone in Diffa or South Darfur, not a laptop in HQ.

Inspiration

Humanitarian caseworkers are running on empty. In a field office in N'Djamena or Maiduguri, a protection caseworker conducts interviews with survivors and displaced people all day, then spends the last two or three hours of the shift writing up what happened. IOM HTCDS forms. UNHCR protection reports. Referral letters. Case notes. Risk assessments meant to flag debt bondage or document confiscation that, in practice, get reduced to checkboxes at the end of a twelve-hour day.

The problem is not that caseworkers lack expertise. It is that documenting one case costs enough cognitive and administrative effort that thoroughness becomes a luxury. Risk indicators go uncaptured. Referral patterns stay invisible. Organizations cannot see the shape of their own caseload because the data never reaches a form anyone can analyze.

I built TRACE after eight years in humanitarian and climate programs watching this play out, and after taking third place at Call for Code AI: United Against Trafficking, run by the Austin AI Hub with UN Human Rights, working on the same problem. The bottleneck is not the interview. It is everything that happens after the caseworker says goodbye.

Why this belongs in the immigration track

Trafficking is a movement crime. People are recruited in one place and exploited in another, and the great majority of the caseload TRACE is built for has crossed at least one border, usually irregularly, often under coercion or deception about where they were going.

For that population, formal identification is not paperwork. It is the precondition for everything downstream. A person who is never identified as a trafficking survivor is processed as an irregular migrant: liable to detention, liable to return, and cut off from every protection pathway that exists for them in national law and in the Palermo Protocol framework. A person who is identified enters a different system entirely, with access to residence and non-punishment provisions, referral to protection services, and standing in any subsequent case.

The identification decision is made by a caseworker, in a field office, at the end of a long day, on the strength of notes taken during an interview. That is the moment TRACE is built for. Getting the indicators captured and the record structured is the difference between a survivor entering the protection pipeline and disappearing back into the irregular migration one.

This is the front door of the immigration system, several steps upstream of where most tooling starts. It is also where the least software exists.

What it does

A caseworker finishes an interview and captures their notes in TRACE, by dictation or by typing. TRACE returns a structured case record built on the IOM Human Trafficking Case Data Standards: case type, detected source language, age range, sex, nationality, location, recruitment method, control method, exploitation type, presenting needs, risk level, matched CTDC indicators, a short narrative summary and a suggested next step. Free text in fifteen supported source languages, including Hausa, Somali, Wolof, Bambara and Lingala, is translated into English as part of the same pass.

Alongside that, TRACE does four things:

Prompts for indicator coverage while the caseworker writes. A client-side matcher watches the notes against eight CTDC-aligned categories: recruitment method, document control, freedom of movement, wages and debt bondage, type of exploitation, control and coercion, family contact, and duration. Each category carries an interviewing tip written for protection work, for example asking "what happened to your documents?" rather than "why did you give your documents away?" This runs entirely on-device with no API call, so it works with no signal. It is a coverage prompt, not a clinical assessment, and the interface says so.

Scores trafficking risk deterministically, with receipts. A weighted CTDC/IOM indicator set of six indicators (labor recruitment fraud, document confiscation, debt bondage, movement restriction, physical abuse, sexual exploitation) produces a score and a HIGH, MEDIUM or LOW band. Every flag cites the field value or the exact keyword in the notes that triggered it. No flag is raised without a citation the caseworker can check. The pre-loaded demo case reads HIGH at 7.5, on four of the six indicators.

Surfaces referral options offline. A cached directory of IOM, UNHCR and NGO partners across Chad and the Lake Chad Basin, filterable by service type, including whether a provider accepts minors. It ships in the bundle, so it is available with no connection, and it pre-populates referral letters so nobody has to recall a phone number from memory.

Drafts the paperwork. Ten document types generate from the structured record: referral letter, case summary, IOM HTCDS form, risk assessment report, family tracing request, reintegration plan, safe exit plan, safe information card, and a supervisor handoff brief. Every draft is editable and every one is reviewed by the caseworker before it is used.

Case data is written to the device first. Nothing leaves it until the caseworker saves, and when there is no connection the record is held in a local browser store and synced when connectivity returns. In environments where connectivity is unreliable and device seizure is a real risk, background push-sync is the wrong default.

The caseworker reviews every AI output before it enters the record. TRACE is a cognitive partner, not an autonomous actor. Survivors never interact with it.

How we built it

Interface. React 18, Vite and Tailwind CSS, mobile-first at 390px, shipped as an installable progressive web app through vite-plugin-pwa. The service worker precaches the shell so the app opens with no connection. i18next drives the interface in four languages (English, French, Spanish, Arabic), with right-to-left layout for Arabic. Interface translation currently covers navigation and core labels only; the rest of the interface renders in English in every language. Hausa, Arabic, French, and English are separately selectable for voice intake, and generated documents can be produced in English or French.

Voice. Dictation uses the browser Web Speech API. It is currently pinned to an English locale and needs connectivity, which is why typed and pasted intake is a first-class path rather than a fallback, and why the language coverage above describes the structuring step rather than the microphone. Dedicated low-resource speech models are the planned replacement so that Hausa, Fulfulde and Zarma can be dictated rather than typed. The likely candidate is Meta's Omnilingual ASR: Apache 2.0, and it covers Sahel languages that Whisper and SeamlessM4T both miss. That work is not in this build.

AI structuring and reasoning. Anthropic's Claude, called through Vercel serverless functions so the API key never reaches the browser bundle. The structuring prompt returns strict JSON against the HTCDS key set, instructs the model to leave a field empty rather than infer it, and forbids emitting a real personal name. The case chat and every document generator stream from the same proxy with the case context injected, so the assistant answers about the case in front of the caseworker rather than in the abstract. A high-risk case with no active supervisor session is held for approval rather than closed silently.

Data. The production architecture uses Supabase for authentication and a cases table with row-level security scoping records to the caseworker who created them. Offline intakes queue in IndexedDB and flush on reconnection once a session exists. Case status, follow-up tasks and an append-only transfer log (who handed a case to whom, when, under what access level) persist locally so chain of custody survives a reload. The demonstration build at the link above runs without database configuration; all data shown is synthetic.

Deployment. Vercel. Nothing to install on the field side beyond a browser and a mid-range Android phone.

What we built during the submission window, and what existed before

Required disclosure, stated plainly.

Existed before. TRACE began as a prototype built for Call for Code AI: United Against Trafficking (Austin AI Hub x UN Human Rights), where it placed third. That build is public at github.com/ElkeDikoume/trace-prototype and established the core: voice or text intake, Claude-based structuring into IOM HTCDS fields, the deterministic CTDC risk scorer with citations, the cached referral directory, and document generation. It is linked here as the hands-on demo because it is the build that accepts free-form input from someone who has never seen it before.

Built during this window, in github.com/ElkeDikoume/trace-humanitarian:

• A complete interface rebuild. A mobile-first shell at 390px that becomes a desktop layout above 1024px, five-tab navigation, dark theme, and a guided walkthrough with a shareable ?tour=1 link that opens the demo with no sign-in and no profile form.
• Streaming document and case-chat modules against the Claude proxy, replacing the request-response pattern.
• A server-side abuse guard on the Claude endpoints with an origin allowlist and an optional shared-token gate, so the endpoints are not an open proxy.
• Local persistence for cases and field notes, so a record survives a reload rather than living only in memory.
• Internationalisation consolidated onto four fully translated locales, and thirteen machine transliterations deliberately removed because no native speaker had reviewed them.
• A full claims audit of the build. Every figure, source attribution and capability statement that could not be verified against the code was removed or relabelled as sample data. That work is visible in the commit history and in the README.

Carried across both: the problem framing, the IOM HTCDS field schema, and the CTDC indicator set.

Challenges we ran into

Low-resource language support is the constraint that has not fully yielded. Mainstream speech-to-text handles Hausa, Fulfulde and Zarma poorly, and the browser speech API does not offer them at all. The working compromise is to let the caseworker type or paste in the source language and have the model translate and structure in one pass, which covers the documentation gap but not the hands-free one. Closing that properly means a dedicated speech model, and it is the top item on the technical roadmap.

Offline-first architecture meant discarding the assumption that data lives in the cloud and is reachable from anywhere. Building around device-first storage with deliberate sync introduced real work on queueing, conflict resolution and deletion, and it forced a split between what must run locally (indicator matching, the service directory, the risk scorer) and what may depend on the network (transcription, structuring, document drafting).

AI accuracy on sensitive data. Risk assessment in protection work is high-stakes. The response is structural rather than rhetorical: the deterministic scorer is keyword and field matching rather than a model, so its output is reproducible and inspectable; the model is instructed to leave fields blank rather than infer them; every generated document is a draft; and no output is persisted before a caseworker reviews it.

Institutional framing. Getting humanitarian organizations to trust an AI tool for protection work means showing alignment with the standards they already use: IASC data responsibility guidance, ICRC handbook principles, IOM form structures. That shapes the schema, the wording of every prompt, and the decision to make consent and custody explicit rather than implicit.

Accomplishments that we're proud of

The risk interface shows receipts. Every flag names the field value or the phrase in the notes that produced it, and the score is arithmetic a supervisor can redo by hand. Humanitarian AI has to be auditable by the person accountable for the case, and a deterministic scorer sitting alongside the model is our answer to that.

The indicator coverage prompt runs entirely on-device. A caseworker with no signal still gets nudged toward the questions a CTDC-aligned record needs, with phrasing written for protection work rather than for a form.

The whole thing is a progressive web app that installs on a mid-range Android phone and opens with no connection. No procurement, no device management, no IT footprint in the country office.

What we learned

The gap in humanitarian field tech is not model capability. It is context: what IOM HTCDS forms require, what CTDC indicators mean during an actual interview, how to phrase a question about documents without implying the survivor was careless, what data protection means when the device might be seized, and what a caseworker has to get done between the interview and the end of the day. Getting that right took longer than building the AI pipeline, and it is the part that does not transfer from a generic tool.

Data governance

TRACE handles some of the most sensitive personal data in humanitarian work: identifying details about people who have been trafficked, in contexts where exposure can be lethal. The governance position is therefore stated rather than implied.

Where data lives. Case data is written to the device first. Nothing leaves it until the caseworker saves. When there is no connection the record is held in a local browser store and syncs when connectivity returns. There is no background push-sync, because in environments where device seizure is a real risk, silent upload is the wrong default.

Who holds it. The demonstration build runs with no database configured and all data shown is synthetic. The production architecture uses Supabase with row-level security scoping records to the caseworker who created them. That is appropriate for a prototype and not for a deployment. Per-organization storage, so that a country office syncs to its own instance and retains custody of its own records, is the prerequisite for any pilot involving real case data.

Who can erase it. Today the device holder can clear all local data from Settings. Administrator-triggered remote wipe and organization-level retention policy are designed for and not built.

What must be true before one real case is entered. Organization-hosted storage, a signed data-sharing agreement with the deploying office, consent captured as a gate on record creation rather than as a separate form, and practitioner review of the indicator set by the protection team that will use it. None of those are met today, which is why nothing in this submission is a real case.

What's next for TRACE

Caseload-level analytics. The problem statement above names organizations' inability to see the shape of their own caseload. TRACE closes the capture half of that today: structured records and an append-only transfer log. Aggregating across a caseload is designed for and deliberately not built, because an analytics view over synthetic cases would be a demo of a number rather than a number.

Organization-hosted data. Today TRACE runs against a single managed Supabase project, which is appropriate for a prototype and not for a deployment. The architecture is designed to support per-organization storage, so a country office syncs to its own instance and retains custody. That is the prerequisite for any pilot involving real case data.

Administrator controls for lost and seized devices. Today local data can be cleared by reloading the app with ?reset in the URL. A proper in-app control, and the administrator-triggered and policy-enforced versions, are roadmap.

Consent as a gate, not a form. A consent record with scope, language of explanation, guardian consent for minors and right-to-withdraw exists in the form library. The next step is to make confirmation a precondition of creating a session record rather than a separate document, and to carry it with the case on transfer.

Speech for low-resource languages, so the languages already supported for typed intake can be dictated.

Indicator frameworks beyond trafficking. The CTDC set is implemented. GBV and child protection are the next two, and each needs practitioner review before it ships, because an indicator set that flags the wrong thing in protection work is worse than no indicator set.

Partner deployment. We are in conversation with field organizations about a structured thirty-day pilot in one country office, contingent on the data-custody work above.

Notes for judges

Tracks: Best Immigration Solution, and 1st Best Overall Hack.

No account is required for either build. Two links are provided deliberately.

The prototype is the one to put your own words into. On its welcome screen choose "Take a guided tour" for the scripted walkthrough, or "Try it yourself" to explore freely with the pre-loaded case.

The v2 rebuild at tracefield.org opens its walkthrough directly at /?tour=1. It is the interface work described above and it runs on scripted sample data, so it is best read as the product direction rather than a free-form sandbox.

The "Sign in with Microsoft" button on both is present for organizational deployment and is not wired to a tenant; please use one of the other two options.

The demo video shows the prototype, which is the build linked as the primary demo.

TRACE is a prototype. The service directory, the pre-loaded case and the caseload shown in the demo are synthetic. No real case data has been processed.

Built With

• anthropic
• claude
• i18next
• indexeddb
• javascript
• pwa
• react
• supabase
• tailwindcss
• vercel
• vite