A tool to help disabled people find support
In New Zealand, disability support exists — but finding it can be harder than qualifying for it.
Volition, a social enterprise working in this space, asked me to build something unusual: a tool to help people navigate a system spread across eight government agencies, dozens of programs, and years of accumulated confusion.
Before building anything, I needed to understand the system — which was harder than expected.
I'm not from New Zealand, and had never interacted with its disability support system. During an early scoping call, Erika — Volition's CEO — walked me through the landscape. I started sketching a map as she talked.
It was VERY complicated.
Understanding the problem
Unlike Australia's centralised NDIS, New Zealand's support system is fragmented across eight different government agencies — resulting in uneven coverage, conflicting eligibility criteria, and widespread confusion.
This fragmentation creates a fundamental problem: no single path exists to find what you're entitled to.
To understand why, consider two people trying to navigate the system.
Sarah, 38, is finally seeking help caring for her 9-year-old son, who is having increasingly frequent meltdowns.
A school counsellor mentions Child Disability Allowance. Sarah applies through Work and Income.
→ Declined. His needs don't exceed "normal care" for his age, despite his Fetal Alcohol Spectrum Disorder diagnosis.
Someone suggests Carer Support — she calls the Ministry of Disabled People.
→ Oops. As of late 2024, DSS has moved to MSD. She's told to start again there.
She applies via MSD and is referred to a NASC agency for an assessment.
→ Declined. FASD isn't recognised as an eligible disability. His IQ is 72 — two points above the threshold for intellectual disability.
Finally, someone mentions Enabling Good Lives — a programme designed for exactly this situation.
→ Not quite. It only operates in Christchurch, Waikato, and MidCentral. Sarah lives in Wellington.
Jordan, 34, acquires a spinal injury in a cycling crash.
Jordan applies to ACC for weekly compensation while recovering.
→ Declined. ACC pays up to 80% of your income — but Jordan wasn't working at the time of the accident.
"Sign up for Supported Living Payment" — since Jordan can only work part-time due to his disability.
→ Not yet. His disability isn't considered "permanent" — he needs medical evidence it'll last 2+ years.
A friend mentions Disability Allowance for ongoing costs like medications and transport.
→ Dead end. Jordan's part-time income is slightly too high. He earns too much to get support, but too little to cover his expenses.
Every step in these journeys is based on real eligibility rules. The core issue isn't the lack of support — it's that support is heavily fragmented across various programs and providers. And no existing tool handles it well.
Why existing approaches fail
The form approach
You could join all the individual questionnaires into a mega-questionnaire. But to assess eligibility for 24 benefits, you'd need to ask 95 binary questions, leading to 71,000 distinct viable journeys — each one requiring pre-programmed logic.
Think of it like Hangman. A bad player guesses randomly — cycling through every letter hoping something sticks. A conditional form does the same: it has to pre-program every possible branch, hoping you land on the right path.
The MSD's "Check what you might get" form sidesteps this by asking only 17 questions — but the tradeoff is a vague list of 50 "options you might get."
Jordan answers all 17 questions. The result? A list of 50 programmes he's never heard of, with no indication of which ones he actually qualifies for. He'd have to research each individually — or call each agency — to find out. That's exhausting when you're already stretched thin financially and physically.
And despite only making vague recommendations, the form still makes incorrect claims — like suggesting Jordan, a 34-year-old with no dependents, might qualify for Away from Home Allowance, a weekly payment for carers of 16–17-year-olds.
The ChatGPT approach
The obvious modern solution: just ask ChatGPT.
ChatGPT fires back with a confident, comprehensive-looking list: ACC weekly compensation. Supported Living Payment. Disability Allowance. Child Disability Allowance. The Invalid's Benefit. And others. For each one, it offers reassuring explanations of why Jordan might qualify.
The problem: some of these are just wrong. Child Disability Allowance requires dependents under 18 — Jordan has none. The Invalid's Benefit was discontinued in 2013. Supported Living Payment requires a permanently established disability, which Jordan hasn't medically proven yet.
The deeper problem: ChatGPT predicts plausible answers. It doesn't systematically verify eligibility. Nothing signals which leads are dead ends. The list looks authoritative. Jordan spends the next month chasing each one — filling out applications, gathering documents, waiting weeks for responses — only to hit rejection after rejection.
In Hangman terms, a good player doesn't guess randomly — they use what they already know. Reveal that the word ends in -ING and you can immediately skip most of the alphabet. ChatGPT skips straight to guessing letters at random.
The form drowns you in options. ChatGPT invents them. Neither checks if any of it is actually true.
Building Navigator
The challenge was clear: we couldn't just prompt engineer our way into a usable product. Raw LLMs get worse as conversations get longer. Instead, we needed a framework to guide the LLM and keep it focused on systematic verification.
At a high level, Navigator works as a loop:
The system has two main parts:
A chatbot web application
- Retrieves information from a manually managed knowledge base
- Answers users' questions and suggests relevant grants or benefits
An admin web interface
- Manages Navigator's knowledge base (Word docs, PDFs, and other text files)
Navigator in Action
Navigator behaves less like a chatbot and more like a guided eligibility assistant — packed with specialised generative UI components that improve accessibility and transparency.
Instead of typing answers to every question, the LLM generates a user discovery interface that lets users tap to answer:
Crucially, transparency matters. LLMs are something of a black box, so limiting their agency is important. Navigator generates a component showing which entitlements were excluded and why — so users aren't left guessing:
Navigator doesn't decide eligibility on its own. Instead, it delegates to specialised agents, each responsible for checking eligibility for a single entitlement:
The result is a system that behaves less like a chatbot and more like a structured eligibility assistant — one that asks the right questions, explains its reasoning, and avoids sending people down dead ends.
What Made This Work
Systematic verification over confident guessing
Instead of an LLM predicting likely benefits, we built agents that check each entitlement's eligibility rules explicitly. This required structuring the knowledge base not as documents, but as verifiable criteria.
Guardrails against hallucination
Managing an LLM across dozens of eligibility checks requires constraint. We built:
- Schema-based responses (agents return structured data, not freeform text)
- Fact-checking loops (agents re-verify against the knowledge base)
- Explicit scope boundaries (each agent only evaluates its assigned entitlement)
Knowledge management as a first-class problem
The admin interface isn't an afterthought — it's core to the system. Eligibility rules change. Programs launch and sunset. The system needs to stay current without requiring code changes.
The road ahead
We've built something great, but still need support.
Navigator isn't a startup. There's no growth metric, no Series A.
You don't build something like Navigator because it's commercially obvious. You build it because it matters.