Project proposal

Nīkau

Co-written with Jove Tondo for SD205 Integrated Studio III

A web platform that helps New Zealand disability support workers and coordinators find community activities for their clients. An AI service suggests activities from a checked catalogue and explains each one in plain language.

Proposal, with the build running September to November 2026.

Community participation is a standard goal in New Zealand disability support plans. In practice, finding suitable activities depends on what each support worker or coordinator already knows. No structured tool helps them match activities to a client's goals, interests and support needs.

Workers fill the gap with council directories and general web search. The matching happens in their head, so it is limited to what they already know to look for. From experience in disability support, workers often do this research in unpaid time, outside their funded hours.

Activity recommenders do exist, but most are built for the end user rather than the person planning support. Few explain why they suggested something.

Nīkau compares a client's goals, interests and support needs against a catalogue of activities and returns a short list of leads. A lead makes no claim to be a decision. The worker still makes the calls and confirms what a website does not say.

Every suggestion comes with a plain-language explanation. It names the goal, interest or need the activity meets. There is no score or confidence value.

Each explanation also says what the activity does not meet. Practitioners tend to trust AI recommendations that agree with their own view and question the ones that do not. An explanation that only gives reasons for an activity risks feeding that bias. Naming the gaps, such as no accessible transport on that route, gives the worker something to ask about.

Activities are entered by hand, and a person checks every record before a worker sees it. Each one records location, cost, transport, physical demand and sensory load.

Nīkau is two services, deployed separately. A Core API holds client profiles and the activity catalogue. An AI matching service ranks activities and writes the explanations.

The service boundary is also the privacy boundary, because everything that crosses it goes to an external model provider. Only the fields needed to rank an activity cross it, with no identifying client details. That makes it possible to check exactly what is sent, which matters under the Health Information Privacy Code 2020.

If the matching service is down, the Core API still serves the catalogue with manual filtering.

On Gemini's free tier, Google may use submitted content to improve its products. The prototype therefore uses made-up client profiles only.

Does running matching as its own service help?

Splitting services does not improve performance by itself. We will compare the matching service's response time and uptime over HTTP against the same logic called directly inside the Core API. We will also test it under simulated load and failure, and check it can be redeployed without touching the Core API.

Can workers trust and act on the explanations?

A small group of support workers will review sample recommendations with and without explanations, using made-up client profiles. We will also count how many leads a worker saves out of those shown.

Frontend: React with Vite, deployed to Vercel.

Backend: Python with FastAPI for both services.

Data and auth: Supabase (PostgreSQL), with our own JWT check on every Core API request.

Model: Gemini Flash-Lite. A small, fast model suits ranking a short list.

The build runs as eight one-week sprints, from 28 September to 21 November 2026.

Weeks 1 to 2: tools, wireframes, database schema, authentication and the Core API skeleton.

Weeks 3 to 5: client profiles, the activity catalogue, the matching service, saved leads, and the fallback for when matching is down.

Weeks 6 to 7: security and integration testing, deployment, and the evaluation for both research questions.

Week 8: report and presentation.

From week 3 we start entering and checking real Wellington activities for the catalogue.

Nīkau is not expected to improve community participation on its own. Its aim is narrower: less time spent searching, and better leads to follow up.

The catalogue cannot be complete. The details that decide a match are often not published anywhere.

Saved leads show whether a worker judged a lead worth following up, not whether the client went. Recording attendance is a planned extension.

The full proposal, with the literature review and references, is available on request. Get in touch.