Liaison - Inter-Agency Coordination, Built Around Consent By Muhammad Aarij & Dylan Whitbread Track and specific problem We chose Track 1: Inter-Org Referral and Care Coordination. Within that track, we focused on the duplicate-detection-and-merge problem - the reality that a single person experiencing homelessness in Victoria can exist as three or more separate client records across different agencies, under slightly different name spellings, with no system aware of the connection. We chose this specific cut of the problem because it sits underneath every other coordination failure. A caseworker can't surface a stalled referral, can't see whether a client is already enrolled at a partner clinic, can't generate an honest by-name list - none of that works if the system can't first answer the question "are these two records the same human being?" Duplicate detection is the foundation. We wanted to do it well, and we wanted to do it in a way that respects the legal and cultural constraints most software in this space ignores: BC's PIPA, withdrawn consent, scope-of-sharing limits, and OCAP principles for Indigenous client data. Before writing a line of code, one of us spent Friday on the ground in Victoria - at Our Place Society, with outreach to Cool Aid and Mustard Seed - to pressure-test what the actual pain felt like for frontline workers, not just what the synthetic data suggested. That field research shaped every product decision below. What we built We built Liaison: a single-screen morning brief for caseworkers that surfaces likely duplicate client records across partner agencies, explains its reasoning transparently, enforces consent and OCAP rules at the code level, and produces a real downloadable artifact (a resolved-clients CSV) that an agency could actually consume. It has five connected views: Before & After - a side-by-side timestamped walkthrough of the same Monday morning at Our Place Society, today versus with Liaison. Today: 52 minutes of phone calls and emails before service begins. With Liaison: 3 minutes. This is the workflow contract we're holding ourselves to. The Morning Brief - the caseworker's first screen of the day. A queue of potential duplicate pairs, ranked by confidence, each one explaining why the system thinks they're the same person (phonetic name match scores, DOB normalization, alias overlap, phone match, temporal proximity). Three demo cards walk through the three states the system has to handle: a happy-path match ready for review, an OCAP-protected match the system refuses to auto-resolve, and a withdrawn-consent record that has been suppressed from view before the caseworker ever sees it. Intake Assist - a live cross-agency lookup that runs as a caseworker types a new client's name at intake. The goal is to catch a likely existing record before a duplicate is created, instead of trying to merge it after the fact. Consent-filtered, OCAP-aware. This was directly inspired by what we heard at Our Place: the moment of duplicate-creation is the cheapest moment to prevent it. Case Review - the deep-dive when a caseworker clicks into a candidate match. Side-by-side dossiers from each agency, recent-encounter timelines, full match-reasoning panel, full consent and DSA status. When the caseworker confirms a match, a modal opens that pre-fills consolidated fields (most-recent-wins, aliases unioned, primary stewardship org assigned) and lets her edit each field before committing. Nothing is auto-merged. Audit & Output - every decision is logged: confirmed matches, rejected matches, system-auto-held OCAP cases, system-auto-suppressed withdrawn-consent cases, and red-flag pattern detections. The session also produces a downloadable resolved_clients.csv - confirmed merges write one consolidated row, rejections write two separate rows tagged distinct_person. This is the handoff artifact a real agency would feed into HIFIS. Under the hood, the matching engine combines jellyfish phonetic similarity for given names, Jaro-Winkler distance for surnames, DOB format normalization (handling YYYY-MM-DD, MM/DD/YYYY, "July 12 1984," and partial dates), alias cross-referencing, and a phone-number match signal. Each pair gets a transparent score from 0 to 1 with per-signal breakdowns. We benchmarked against the kit's seeded truth set (300 true positives, 200 decoys) - current F1 is [F1 number to be filled in from Dylan's run], beating the kit's baseline of 0.65. The OCAP guard is enforced at the data-access layer: if either client in a candidate pair has ocap_protected=true and the two organizations don't have an executed data-sharing agreement covering the governing Nation, the system holds the match and routes the question to the agency's Indigenous Liaison - it does not present the records as a mergeable pair. The withdrawn-consent suppressor runs before any cross-org view is built, so a record whose owner has revoked consent never appears in another caseworker's queue at all. How a frontline operator uses it on a real Monday morning Maria is a caseworker at Our Place Society. She arrives at 8:42 AM. A walk-in is at the front desk - reception thinks the name sounds familiar but isn't sure. Today, that uncertainty triggers 50 minutes of detective work - 14 ambiguous matches in a HIFIS name search, three emailed agencies, a phone call to Cool Aid that goes on hold for six minutes, and ultimately a new client record created with "possibly known to Cool Aid" typed into a free-text notes field. Meanwhile the person at the desk is still waiting. With Liaison, the same morning looks like this. Reception types "Sarah Thompson, 1984-07-12" into Intake Assist. Within 200ms, the system surfaces two likely existing records across the nine partner agencies - one at Cool Aid Society at 91% confidence, one at Pacifica that is held because the client is OCAP-protected under Songhees Nation and the Pacifica DSA doesn't cover that Nation. Maria sees both - but she only sees the fact of the OCAP hold, not the underlying record. The system tells her exactly who to contact (the Indigenous Liaison routes the request, not Maria directly) and explains why this can't be auto-resolved. For the Cool Aid match, Maria opens the case review. She sees Sarah's name spelled "Sara Thomson" at Cool Aid, the same DOB after format normalization, the same phone number, "Sarah Thompson" listed as an alias on the Cool Aid record, encounters at both orgs within 72 hours, an active PIPA consent at both orgs, and a sharing scope (DSA-008, South Island Coordinated Access Table) that explicitly covers cross-agency care coordination. She confirms the match. The merge modal opens with a consolidated record pre-filled - she tweaks the alias field, commits, and one row is appended to resolved_clients.csv. The decision is logged with a hash, her email as actor, and the Nation status. From walk-in to service, three minutes. If Maria had instead clicked "Not a match," both clients would have been written to the CSV as separate rows with distinct_person tags and cross-references - so her judgment is preserved as data, not lost as silence. The screen is designed so that none of this requires training. The visual register is editorial - Fraunces and Public Sans, warm paper palette - closer to a newspaper than a SaaS dashboard, because the people who will use this are caseworkers, not engineers. Every action she might take is one click. Every decision is reversible until committed. What we might would ship next with one more week In priority order:
- A real pilot with one of the orgs we visited. This week we built against synthetic data. The next step is to take Liaison back to Our Place, Cool Aid, or Mustard Seed and ask them to spend an hour clicking through it with us - paid time, not volunteer - and tell us what's wrong. Field research before the build was step one. Field research after the build is step two, and it would change the product more than any feature we could code in seven days.
- A read-only HIFIS adapter. Right now Liaison reads the kit's parquet files. The next engineering step is a connector layer that reads HIFIS 4 client and encounter tables in a read-only mode, with the resolved-clients CSV writing back through a supervised approval queue - never a direct write. This keeps Liaison non-disruptive: it sits beside the agency's system of record, not on top of it.
- A formal OCAP governance flow. We have the technical hold in place. The week-two work is the process - a structured workflow for Indigenous Liaisons to request scope amendments from a Nation, attach the Nation's response to the audit ledger, and make that decision reusable for future matches involving the same client. This is the difference between respecting OCAP and operationalizing it.
- A supervisor approval lane for confirmed merges. Currently a caseworker's confirmed match writes immediately to the CSV. A more production-ready flow would queue it for a supervisor (compliance reviewer, program lead) before it becomes the canonical golden record. This protects against well-intentioned mistakes and gives agencies an internal review surface.
- The rest of the four problem areas. Track 1 named four sub-problems and we deliberately went deep on one. The matching engine and the consent layer we built are reusable infrastructure for the other three: consent-gap surfacing, referral-lifecycle analytics, and falling-through-the-cracks risk detection. With one more week we'd extend the same morning brief to surface stalled referrals and chronic-vulnerable clients who've gone quiet - same screen, same caseworker, same trust model. The deeper commitment, though, isn't a feature list. It's that no further version ships without further field research. Liaison's measure of success is not its F1 score. It's whether a caseworker at Our Place would actually open it on a Monday morning.
