Gate bug fix, Article 9 consent, immigration status flow, LGBTQ+ specialist, early flow gates#9
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| ...phrase('ACCESS_LOCATION_ASK', session.isSupporter), | ||
| stateUpdates: { | ||
| currentGate: 'ACCESS_LOCATION_ASK', | ||
| preferredName: skipped ? null : nameInput |
There was a problem hiding this comment.
I might be missing something but preferredName is a free-text field that accepts names, which is PII. The data minimisation note says the VA doesn't collect identifying personal data and doesn't ask for names, address, DOB etc. This seems to contradict that.
The field is also write-only. Nothing in the handlers, terminal builder, or service matcher reads it, so it's collecting data with no functional purpose.
If the intent is reach intelligence or outcome tracking, that's a different processing purpose from routing to support services and would need governance justification.
Might be worth pulling out and handling separately.
There was a problem hiding this comment.
the plan was to make sure that this is used simply for conversational purposes because it sounds friendlier if someone is addressed by a name. It is meant to be worded in such a way that it says what would you like to be known as rather than asking for an actual name. It is conversational. I don't think that breaches anything from a governance perspective but if you think it doesnt add anything to the user experience then we can take it out.
There was a problem hiding this comment.
I take your point about the conversational tone, intent isn't an issue, it's the mechanism: a free-text field will collect real names most of the time regardless of how the question is worded.
If the goal is warmth, there might be ways to achieve that without a name field.
There was a problem hiding this comment.
ok we can explore that.
There was a problem hiding this comment.
Super. Appreciate that I'm probably being pedantic. You've set a great standard with the governance docs, so aligning with them feels important
There was a problem hiding this comment.
Thanks James. Maybe that is why we can make it work. Governance is my speciality, yours is coding and Claude meets us in the middle. I have some quite awersome governance work to show you when you get back.
| }; | ||
| } | ||
|
|
||
| case 'ACCESS_LOCATION_ASK': { |
There was a problem hiding this comment.
Similar concern for accessLocation, returnUser, and returnOutcome. All three are stored but nothing reads them as things stand. I can see the analytics value, but collecting before the consumption mechanism doesn't sit well with the governance note's own position that collecting data the pathway doesn't require would be a violation.
A clean solution would be to defer these until the analytics side is build, or update the governance docs to cover the separate purpose.
There was a problem hiding this comment.
This might need a slight amendment to the governance note preferably.
You're right that collecting before the consumption mechanism is built is a grey area.
-
accessLocation tells us where people are using the VA so we can ensure accessibility across devices and contexts. That's a direct operational purpose.
-
returnUser tells us whether we're reaching new people or the same people coming back. That's reach intelligence, not individual tracking. I kow that WMCA are asking us if we can track this. If we don't think we can defend i thenwe won't but I think we can find a justification.
-
returnOutcome tells us whether the VA led to contact with a service. That's the closest thing we have to measuring whether the system works.
We are limiting any intelligence reach questions as far as possible to ones that are probative. But yes wshould include this within the governance as an exception unless you have a major objection.
There was a problem hiding this comment.
The operational arguments make sense, particularly the WMCA reach question and outcome measurement. No major objection to collecting these in principle.
The issue is sequencing: the governance note currently says collecting data the pathway doesn't require would be a violation, and these fields don't affect routing. If we update the note first (or alongside this PR) to cover a separate "operational intelligence" purpose with its own lawful basis, that's fine. I'd rather not merge code that contradicts its own governance docs and fix the docs afterwards.
Can you add a short section to the Data Minimisation note covering these three fields, their purpose, and the lawful basis? Then we can mark this one as resolved.
There was a problem hiding this comment.
-
Data Minimisation Note v1.1 new section between "Purpose Limitation" and "Outstanding Governance Actions" covering operational intelligence fields. Three fields, three purposes, same lawful basis (legitimate interests), separate from the routing purpose. The key argument: these serve the service's operational improvement and accessibility obligations, not the individual's routing pathway. They are non-identifying, session-only, and enumerated (not free text).
-
Analytics Contract add "Operational Intelligence Events" as a new event type alongside Routing Events, State Resolution Events, etc. Three permitted fields: access context (device/location type), return status (new/returning), outcome action (contacted/not contacted). All enumerated values only.
-
Quick Route Design Note v1.1: the governance reasoning section needs one line clarifying that the "no governance basis for asking" principle applies to routing questions. Operational intelligence questions (accessibility monitoring, reach measurement, outcome tracking) have a separate governance basis documented in the Data Minimisation Note.
Think that covers it.
|
|
||
| // TODO: Wire housingOptionsInvolvement into buildTerminalServices — when true, | ||
| // deprioritise Housing Options in terminal output and lead with navigator/specialist orgs instead | ||
| case 'HOUSING_OPTIONS_INVOLVEMENT_ASK': { |
There was a problem hiding this comment.
HOUSING_OPTIONS_INVOLVEMENT_ASK now sits between B6 and B7 for every housing user but there's no test coverage for it. Could we add at least a couple of tests verifying the routing through the new gate? Without them a regression here could break the housing pathway silently.
|
@camlambert2000 The 9 housing options tests exist on the staging branch (commit 12365ca) but the PR is pointing at the pr/staging-v2 branch, which doesn't have that commit yet. They're two different branches that have diverged. You'll need to either push the test commit to pr/staging-v2, or update the PR to point at staging instead. As it stands, the PR diff on GitHub won't show the tests. |
camlambert2000
force-pushed
the
pr/staging-v2
branch
from
a7b6c61 to
12365ca
Compare
|
the 9 housing options tests are now visible in the diff (commit 12365ca). 63 tests passing. |
james-cross
force-pushed
the
pr/staging-v2
branch
from
12365ca to
04b0e69
Compare
…sing options involvement Re-applies all staging work after PR #7 revert. Includes: - Immigration status value alignment and state propagation fix - LGBTQ+ prefer-not-to-say loop fix and specialist field consolidation - Dead code removal (B5_PROFILE_NRPF, SPECIAL_CATEGORY_CONSENT) - Early flow gates (preferred name, access location, return user) - Housing options involvement question Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
james-cross
force-pushed
the
pr/staging-v2
branch
from
04b0e69 to
f2bc45f
Compare
2 participants
Commits 1-4: Gate bug fix, Article 9 consent gate, immigration status flow, LGBTQ+ specialist preference (previously reviewed in PR #7 notes).
Commit 5: LGBTQ prefer-not-to-say loop fix, specialist field consolidation, dead code removal (addressing James's feedback on PR #7).
Commit 6: Early flow gates — preferred name, access location, return user, housing options involvement (new, not yet reviewed).
63 tests passing.
🤖 Generated with Claude Code