Private interaction prototype · 8 September 2026

What survives
a reconnect?

The connection can change.
The user's goal should remain explicit.

A simulated interface for examining one design choice. No VPN connection, performance measurement or customer study runs here.

Proposed interaction

A retry that remembers the goal

You asked the app to prioritize speed. It selected Paris. When that connection fails, the next attempt should preserve the preferences you chose. Speed and a fixed city can matter together.

ConnectionSimulation
Your goalPrioritize speed

Connection interrupted

Your last connection was in Paris. We can look again with speed as the priority.

Speed has not been measured.

Change what matters

Choose speed, a fixed city, or both. The next attempt preserves your selection.

What the interaction preserves

A retry keeps “Prioritize speed”. Paris is the previous location, not a location you chose.

Recorded source behavior

In the test, the request changed

An observed request sequence, not a recording of the installed app.

A test using the actual client connection stores began with the speed intent. Mocked services returned a residential connection in Paris. On refresh, the next request retained that location and IP type, while its intent field was empty.

Initial request

Goal sent
Speed
Country / city
Not specified
IP type
Not specified

Refresh request

Goal sent
No intent field value
Country / city
France / Paris
IP type
Residential

The open question: does location preservation match what someone expects from this retry? No intended refresh contract was found, and the backend's interpretation was not tested. This alone does not establish a product defect.

Inspect the source and test boundary

Client revision bc6f8eab00472f8b3785a5a937481e653273020c; source manifest 2.4.9 dev. The inspected recovery files also matched the earlier build-219 candidate revision. The installed binary was not bound to these source bytes.

The test exercised actual VpnStore, ConnectionDecisionStore and ConnectionRequest, with a fake intent store and mocked repositories and services. Four selected unit tests passed in the recorded run. It measured no tunnel, playback, game, user effort or commercial outcome.

Pinned public client source. The retained local test record is consumer-intents/recovery-unit-record.json in this research project.

The proposed interface above is authored for this study. Its screens and simulated connection results are not extracted from the client.

    

    

      Research question
Less interpretation left to the user
A plausible benefit to test, not a measured advantage.

      
The interesting possibility is an interface that remembers why the connection exists, explains a necessary trade-off, and distinguishes “connected” from “your goal was achieved”. That benefit could exist even with familiar networking underneath.

      
A stronger comparison: Proton’s Profiles documentation already combines location constraints with fastest-server selection. NordVPN introduced activity presets, then documented their removal in macOS 9.0 in favor of Quick Connect and country auto-connect. Neither feature availability nor retirement measures customer value.

      
  1. Expectation: before a retry, can people predict what will stay the same?
  2. Comprehension: after it, can they distinguish the connection state from the unmeasured speed outcome?
  3. Burden: does the explicit goal help, or create another choice people did not want?
  4. Real behavior: does a supported implementation preserve the chosen goal through failure without unwanted effects on other traffic?

      
No people have been recruited or contacted for these tests. No production change is proposed by this page. Kairos can develop the research; MN owns customer access, product decisions, merge and release.

    

    

      Record
Scope and source record
A private simulated prototype and its evidence boundary.

      
Prepared for the Kairos team. Kairos operates this private research; MN owns customer access, product decisions, merge and release. Online, the page opens for everyone who signs in to the Kairos War Room, the MN team included.

      
The interaction above is authored and simulated. The source observation is one request sequence from a recorded unit-test run against client revision bc6f8ea, in which four selected tests passed. Still unknown: how the backend reads the refresh request, whether the installed app matches the inspected source, and whether people want their goal kept. The page connects to no VPN, measures no performance, recruits no one and proposes no production change.