How the noticing works.

In one paragraph

The product already records who asked for a ride and who travelled. Once a week it applies a short list of arithmetic rules to those records — for example, "this person has a routine somebody confirmed, and has missed three of the occasions it expected" — and puts the result on one screen inside the agency, for a member of staff to read. Nobody outside the agency sees it. No rider is contacted because of it. A person decides what, if anything, to do.

There is no artificial intelligence in it

This is the question most worth being precise about, because it is the one people assume the answer to. Every notice is produced by a deterministic rule over counts and dates. There is no model, no scoring, no prediction and no inference about anybody's health. The rule that produced any given notice can be shown to the person reading it, with the numbers that triggered it, and they can disagree — and a dispatcher who knows the rider is in hospital is more right than the rule is.

A language model is used elsewhere in the product, to help draft website copy. It has no part in this.

What it will not do

• No scoring or ranking of riders. There is no reliability rating, no risk score, no list of who is worth carrying.
• No prediction gating service. Nothing decides who gets a booking.
• No inference of a medical condition, stored or displayed. The nearest the product comes is the mobility note a rider gave you themselves, in their own words.
• No sharing between agencies. Not aggregated, not anonymised, not for research.
• No automatic contact with a rider from anything inferred. Staff can be texted automatically about a vehicle; a rider cannot be texted because of a pattern. That distinction is structural — there is no function in the codebase capable of composing a rider message from a noticed pattern.

Six things enforced in code, not promised in policy

1. A destination never appears in a notification. A notice says "has not booked her usual Tuesday", never where the Tuesday trip went. Notices are read aloud in offices, forwarded and screenshotted. This is asserted by automated tests against a list of clinical words, on every build.
2. Rider data is unreachable from the marketing side. Mailing lists query a separate table holding no trip data. There is no join from a letter to a journey.
3. Opening a rider's record is itself recorded — who, and when, including us. An agency that cannot answer "who looked at this" cannot honestly promise anything about it.
4. Detail coarsens on a schedule. Per-trip records keep their detail for thirteen months and then collapse into counts. Nobody needs a ten-year map of one person's appointments.
5. Any rider can be exported and erased by the agency, in one action, including their history, patterns and notices.
6. Every notice names the person it serves, in a field, shown on screen. If the honest answer to "who is this for" were the agency's revenue or its attendance statistics, the rule would not exist. That is the test each one had to pass to be built.

Is this health information?

We are not your counsel and this is not advice. What we can tell you is what the system actually holds: who booked a ride, where they were collected, where they asked to go, and whether they travelled. Your agency already holds all of that in whatever it uses today — a scheduling system, a spreadsheet, a paper diary. This product does not create a new category of information about anybody.

What it changes is that a pattern in that existing information becomes visible to a member of your staff. Our position is that a transit agency noticing an elderly rider has stopped coming, and ringing to ask if she is all right, is the ordinary business of a service that carries people — and that the risk worth managing is the disclosure that happens when such a notice is careless about where somebody was going. That is the risk the six rules above are built against.

If your counsel reaches a different conclusion, the feature can be left alone: nothing else in the product depends on it, and an agency that never opens that screen loses no other function.

Where this came from

The design is adapted from a system called NRI, built for a different domain entirely, and the mechanism is shared while none of its vocabulary is. The full build specification — including the list of things we decided not to build, and the argument for each — is in the repository as docs/NOTICING_BUILD_SPEC.md, and we will send it to you on request. We would rather be argued with from the specification than trusted on the strength of a marketing page.