Inspiration

We live in the UAE, a country where housing instability is a daily reality for a huge share of the population — especially low-wage laborers whose accommodation is tied directly to their employer. We wanted to build for that crisis first, because it's the one we see around us.

But when we actually tried to build it, we ran into a wall. Legal information for migrant worker housing in the UAE is fragmented across ministries and almost impossible to verify against past cases. So, we asked a harder question: where could we build this properly while we worked out how to eventually bring it home?

One of us had visited New York City and seen firsthand that this wasn't only a UAE problem. In 2024, more than 126,000 eviction cases were filed in New York City and most tenants face eviction without a lawyer. 89% of tenants with full legal representation stay housed. The difference between keeping a home and losing one often comes down to whether someone reaches the right help in time. NYC has strong tenant protections and real free help, but that help is scattered across agencies, hotlines, and legal jargon, nearly impossible to navigate when panic peaks. People lose their homes not only because the law fails them, but because they can't find the right door in time. Anchor exists to close that gap at the first, most panicked moment.

What it does

Anchor is a triage tool, not a chatbot and not a lawyer. Anyone can type or speak about what's happening in their own words. Anchor reads it, asks one high-leverage question, and returns a single most-urgent action, a short plan, mistakes to avoid, and the exact verified humans to call. The user can print a one-page case file to hand to a counsellor.

The whole product is designed to carry cognitive load: one screen, one question, one urgent action, always ending at a real person.

Features:

  1. Free-text "dump" intake
  2. A severity badge (urgency scored 1–5) and a "what I understand so far" reflection so the user can correct Anchor if it misread the situation
  3. Multi-issue detection — Anchor finds every applicable scenario in what the user describes, ranks them by urgency, and names the most urgent as the primary issue
  4. Scenario-aware resource ranking from 13 verified NYC resources listed and shown on live map.
  5. A printable case file
  6. Accessibility features including read-aloud via browser speech synthesis, voice input via browser speech recognition, tap-to-dial, reduced-motion support.

How we built it

Anchor's intelligence is in routing, not authoring. Its knowledge comes from an 11-situation playbook written from official NYC sources, with every entry dated and cited. The model classifies and routes within verified content only.

The reasoning runs in two distinct passes:

  1. classify. Anchor reads the user's free-text situation, identifies every issue present, ranks them by urgency, and asks the single clarifying question that most changes the next step.
  2. plan. Based on the user's answer, Anchor builds a stage-grounded, scenario-specific plan, pulling only from the sourced playbook entry that matches.

On the front end, we built toward calm rather than alarm — a single-column "earned calm" design using amber rather than red for urgency, so the interface itself doesn't add panic on top of an already panicked moment.

The whole stack is designed for zero-cost deployment: the map runs on Leaflet/OpenStreetMap with no API key or billing, voice input and read-aloud use built-in browser capabilities, and hosting runs on a free tier. The only real marginal cost is cents-per-query inference, meaning a nonprofit could realistically run this tomorrow.

How we tested it

We evaluated Anchor against 25 labeled real-world inputs across all 11 scenarios, including adversarial crisis and low-confidence cases. The system correctly classified 92% (23/25) to the correct primary scenario. Both misses were borderline cases between adjacent scenarios. Crisis and low-confidence inputs were handled correctly, routing to human support when needed. Importantly, classification is not treated as final — every output is grounded in a verified playbook and can escalate to a human when uncertainty is detected.

We also tested across terse low-literacy input, African American Vernacular English, and mixed Spanish-English, since the people who most need housing help are least served by tools built only for standard English. Anchor correctly interpreted non-standard grammar and routed each to the right situation.

Challenges we ran into

The hardest problem was making one situation produce genuinely different plans instead of one averaged, hedge-everything answer. We solved it with stage-grounded prompting tied directly to the user's clarifying answer, rather than a single static response template.

The most important fix came directly from adversarial testing. Our crisis filter missed "my partner hits me" because our first-pass filter only pattern-matched "hit me." So, we added a second, deterministic safety net that re-checks the model's own understanding for crisis signals after the first pass runs — specifically so a domestic violence disclosure can never slip through a single point of failure. When detected, Anchor immediately surfaces the DV hotline regardless of what else is happening in the conversation.

Accomplishments that we're proud of

We are proud of the two-pass reasoning architecture, and specifically the verified answer-fork — being able to show that the same starting situation produces two opposite, correct plans depending on one answer.

We're equally proud of the responsible AI architecture. Anchor never states a legal deadline as fact, but flags urgency and routes the specific, irreversible detail to a verified human. Also, every plan also surfaces a last_verified date and source, both in the UI and in the printable case file, and we say plainly what Anchor doesn't yet cover, like NYCHA-specific procedures, rather than overstating our scope.

What we learned

We learnt that restraint is a feature on its own. The instinct in a hackathon is to make the AI do more — read uploaded documents, state exact deadlines, generate legal filings. We learnt that for a tool people trust with their housing, knowing what to deliberately not answer, and routing that to a human instead, is as important as knowing what to answer. The cost of a confidently wrong date is someone's home, so the architecture has to treat that risk as a first-class design constraint.

We also learned that single-jurisdiction discipline is a strength, not a limitation. It would have been easy to claim broader coverage to sound more impressive. Staying disciplined to NYC only, and saying so clearly, meant every fact in our playbook could actually be verified and dated. This is what makes such a tool reliable in a real crisis.

What's next for Anchor: from housing crisis to first step

We have a few features in mind for the future which we could not implement due to time and reach constraints. These are:

  1. A document-type identifier that can tell a user what kind of notice they're holding, without requiring them to read sensitive details aloud or type them in manually
  2. Direct connections to volunteer housing counsellors.
  3. Multilingual support, starting with Spanish, given the population Anchor is built to serve
  4. Expansion to NYCHA and public-housing-specific situations, which our current playbook deliberately and transparently does not yet cover
  5. Continued quarterly re-verification of the knowledge base against official NYC sources, maintained as a single structured file an advocate could update directly.

Built With

Share this project:

Updates