Private working selection · 10 September 2026

Findings worth
carrying forward.

What the evidence supports.
What it still cannot tell us.

A reading view of selected results from the seven-day Kairos / Mysterium investigation. Evidence through 01:49 Vilnius on September 10. Research remains active through September 14.

Begin with the experience worth building. Then examine which mechanisms could deliver it, what our experiments actually establish, and what remains unknown. Kairos’s product direction guides the ambition; the findings below constrain the claims and suggest the next useful tests.

Kairos direction · evolving product hypothesis

Start with the experience we wish existed

Let the desired result guide the mechanisms, then revise it through use.

A traveller keeps watching while the product handles an ordinary connection problem. They do not need to diagnose it, choose a repair or admire the work. That is the desired experience; the implementation still has to earn it.

What we found

Lee’s adopted Kairos direction combines an evolving ideal with deep system understanding, considered defaults and craft. Applied here, the network, interface, payment and recovery mechanisms should serve a coherent customer experience. Routine invisible work and optional inspection can belong to the same product.

What remains unproved

Adopting that ambition does not establish uninterrupted playback, access to a named service or production recovery timing. The existing simulations and public-trace experiments test narrower questions. Their warnings are analytical signals; they do not require a warning screen, explanation or confirmation dialog in the product.

What would change the conclusion

Use a concrete version to discover what still demands unnecessary attention. Trace the constraint that causes it, improve the whole journey, and revisit the ideal when real use contradicts it. A genuine unresolved decision still needs an understandable path forward.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Personal and fleet learning · research hypothesis

Learn which situations deserve the same response

A familiar symptom is a starting point, not a diagnosis.

A connection fails after the laptop wakes. Last time a fresh connection helped; this time the network itself is unavailable. Useful memory must recognize the difference, and learn when an old lesson no longer applies.

What we found

Close prior art exists: NetPrints used shared configuration and repair knowledge, including VPN cases. It kept exceptions apart when the common configuration model did not explain a failure. Our source trace also found native macOS socket refresh on network changes. These sharpen the proposed AI comparison: learn useful distinctions and improve on the recovery already present.

What remains unproved

NetPrints was a small historical diagnosis study with outcome labels, not an autonomous modern VPN trial. No personal or fleet learner has been evaluated here. A repair followed by recovery does not prove causation. The inspected native source is not yet bound to the shipped binary. More technical history does not remove these limits or justify a personal dossier.

What would change the conclusion

Compare competent existing recovery, simple local history and context-matched shared estimates with the same permitted actions. Preserve minority failures, changing environments and unknown outcomes. Add AI only if it improves the intended activity beyond that baseline at an acceptable cost; prediction accuracy alone cannot establish the benefit of untaken actions.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

GoProxies · commercial hypothesis

Help an existing customer buy again

Repeat purchase, usable allowance and configuration continuity.

Someone who wants another 50 GB may need more than a payment button: the new allowance must arrive and the required connection settings must survive.

What we found

Five examined refill conversations resolve to four captured accounts. One follow-up includes a cancellation request made specifically to buy another subscription, followed by a reported repurchase.

What remains unproved

These are selected support reports. Settled payment, correct entitlement and a successfully completed customer task have not been linked into one observed chain.

What would change the conclusion

A current transition contract and outcome record could distinguish an unresolved fulfillment problem from an old, resolved incident or a misunderstood display.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

VPN revenue · research-method counterexamples

Define what makes a customer better

Explaining a purchase amount is different from measuring a later outcome.

Two authored examples have identical initial sales and revenue. Later repeat purchasing is better in one and worse in the other. Their revenue decomposition cannot tell them apart.

What we found

Exact arithmetic reproduces the deck’s reported +41.5% revenue and −1.7% sales through different mechanisms. With complete compatible groups and actual mean paid amounts, plan mix plus within-plan amount changes explain the whole revenue-per-sale movement by construction. A list-price calculation can instead leave discounts in its remainder.

What remains unproved

These are constructed counterexamples, not MN transaction data or an estimate of customer quality. The deck figures were read directly but not reproduced from the warehouse. This pass was not a blind or independent review.

What would change the conclusion

Define the intended quality outcome independently—such as repeat purchasing over a specified follow-up—then establish its population and coverage. Revenue decomposition can describe the initial movement; its unexplained share cannot stand in for that outcome.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Consumer VPN · source and component test

Get the wanted capability in time

Plan duration, feature access and activation time are different things.

Someone who needs residential access today needs the right capability active today. A longer subscription or an upgrade confirmation alone does not establish that result.

What we found

In four controlled Dart cases, the inspected activation helper stopped at any active subscription, including the previous Basic plan when Plus was requested. If every response remained inactive, it returned an inactive fallback after three attempts. The surrounding source logs payment-verification success on a non-throwing return; a separate UI branch checks active status.

What remains unproved

The helper ran with controlled responses, not native billing or the backend. A scheduled change can legitimately leave the old plan active. These tests do not establish a wrong charge, wrong displayed plan or customer harm. The inspected status model does not explicitly represent a pending target plan and effective time. The relevant blocks remain in the September 9 public source; the earlier tests retain their original version labels.

What would change the conclusion

Establish whether the particular change promises immediate access or a future effective date, then observe the corresponding entitlement. Checking only that some plan is active is insufficient; requiring immediate plan equality could also reject a valid scheduled change.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Consumer VPN · composed source test

Keep the intended action through sign-in

A request can be marked handled before its destination opens.

Someone taps a notification to view Products while signed out. In the controlled source test, they reach login, but signing in does not resume that same request. A new notification after login reaches Products.

What we found

Three Flutter/Beamer tests executed the actual notification reaction, navigation helper and tab store. Products, Subscribe and Upgrade requests were marked handled before their signed-out destination could complete. Changing the auth signal and remounting the handler did not replay that ID; a new ID reached the intended tab or modal handler.

What remains unproved

The auth state, page shell and modal handlers were controlled; returning to Main was an explicit test action. The installed app, native sign-in, actual purchase screens and current campaign exposure were not tested. This establishes a source-composition behavior, not a customer failure rate. The relevant blocks remain in the September 9 public source; the earlier tests retain their original version labels.

What would change the conclusion

Follow a legitimate entry through the supported app-level sign-in journey, with the build and signed-out browsing condition recorded. Distinguish a requested action, login completion, destination presentation and completed task. Preserve access checks while testing whether intent should resume.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Consumer VPN · private source candidate

An old answer must not undo a newer one

Background work needs rules for which result still counts.

The location catalogue refreshes twice. The newer request finishes first; an older response or saved-value notification arrives afterward. In controlled tests of the original store, the older catalogue could replace the newer one. These are catalogue contents, not changes to the active VPN exit.

What we found

A private candidate now passes 24 distinct checks covering shared ordinary requests, superseded responses, failed writes, reopened isolated Hive databases and delayed notifications. Two earlier candidates exposed different failures and remain retained. The current candidate orders writes and checks current storage before accepting a cache notification.

What remains unproved

The tests exercise source code and isolated databases. They do not establish installed-app behavior, customer exposure, account transitions, cancellation or coordination between multiple stores. The candidate adds cache reads and can make a newer write wait behind an older writer. Battery savings and user-facing delay have not been measured.

What would change the conclusion

Treat this as a reviewable candidate for the demonstrated sequences. Broader lifecycle and integration work belongs before any release decision. For the learning investigation, it establishes a prerequisite: extra intelligence cannot compensate for a newer decision being overwritten by obsolete work.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Consumer VPN · product hypothesis

Follow the job beyond the VPN

The interface helps someone achieve an observable result.

A person wants a stream to play, or wants speed while staying in Paris. The useful action could preserve that requirement, reduce competing local traffic, or leave the connection alone.

What we found

A paired private prototype compares settings and goal summaries with identical scripted behavior. Existing alternatives include profiles, local controls, provider-funded recovery and supported offline preparation. They can reduce the need for another network intervention.

What remains unproved

No human comprehension, effort, task benefit or MN demand has been measured. The paired page teaches its answers. A download for another title, device or time is not automatically an equivalent solution; provider documentation does not establish a third-party integration.

What would change the conclusion

Compare the same intended task against applicable existing remedies. Preserve content, device, timing and protection requirements; measure correct understanding, effort and unnecessary intervention separately from actual task completion.

Try the simulated recovery interaction →

Compare two interfaces with the same behavior →

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Two primary papers · product hypothesis

A quiet product can reward curiosity

Make useful work available to inspect without making it another obligation.

After a film, someone might enjoy discovering what the app handled. Someone else may never open that history. Both should get the same good viewing experience.

What we found

One paper found that displayed work could change perceived value in simulated services. Another examined completed-request photos in a civic service and subsequent engagement. They make optional, truthful after-task visibility worth considering; they do not determine its design.

What remains unproved

The papers share authors; they are not independent research programmes. Neither tests this VPN idea or achievements. Perceived value can change without technical improvement. More app openings need not be desirable for a quiet service. Recovery events do not measure minutes or frustration saved.

What would change the conclusion

If implemented, compare quiet service alone with optional plain and playful views of the same real record. Include stable periods and unresolved problems. Judge understanding, enjoyment and unwanted attention separately from task success and commercial results.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Existing product · inspected source and published image

Using connectivity and contributing it are different jobs

A shared network can support different experiences for different roles.

The viewer wants their film to continue. A volunteer wants to help others connect, within limits they chose, and may enjoy seeing that contribution. Separate purposes may justify separate experiences before they justify separate apps.

What we found

Snowflake Volunteer puts volunteering into a standalone Android app even though Orbot already offered that capability. Its published image shows current activity and historical statistics. In the pinned application source, accumulated counters track connection events and transferred bytes.

What remains unproved

These are source and published-image observations, not an installed-device test or evidence of Mysterium demand. The counts do not establish unique people helped or completed tasks. No achievement unlocks are shown in the inspected image. Tor volunteering and paid residential exits have different roles and architecture.

What would change the conclusion

Establish the actual Mysterium contributor journey and available contribution record. Keep buying access, funding a programme and operating connectivity distinct. Then compare whether modes or separate apps better serve those purposes; payment alone cannot supply a measured free-internet impact claim.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Product packaging · evidence and hypothesis

A simple app can still be hard to choose

Evaluate the whole journey: finding it, choosing it and using it.

Someone wants a stable call but does not know what is causing the interruptions. A fleet of specialist apps could simplify the controls yet leave that person choosing the wrong tool. This is a risk to test, not a finding about MN users.

What we found

Krisp and Discord show that a focused feature can live inside a larger app, with different coverage and setup costs. Choice-overload research gives no universal rule that fewer options are better. A historical video-player experiment found different preferences before and after use: initial appeal and experienced satisfaction can favor different products.

What remains unproved

The video-player comparison used different participant groups, not the same people changing their minds. It did not establish a difference in completed-task counts or measure retention. None of these sources establishes MN demand, the best feature count or which package would earn more.

What would change the conclusion

Begin the comparison before handing someone the correct app. Keep unsuitable choices and non-choices visible. Compare the same task and protection requirements, then distinguish initial appeal, setup effort, task completion and satisfaction after use. Declare exposure order and whether the same people supply the before/after judgments. A fleet can share a subscription while leaving apps individually downloadable; its second-app journey must recognize existing access. Platform support establishes a mechanism, not demand. Named operating-system shortcuts backed by one app are another documented option for a known repeat task; initial setup and recurring use need separate observation.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Published product scope · comparator

The browser can include the VPN

A browsing-only product competes with features inside the task application.

An eligible Firefox user can choose a browsing location without installing a separate VPN app. A proposed specialist needs to improve the same task under comparable requirements, rather than assume that extra installation is unavoidable.

What we found

Mozilla documents free browser-scoped routing, location selection and per-site exceptions, with a Mozilla-account requirement and 50 GB monthly allowance. Its announcement describes asking for confirmation before browsing without IP protection after the allowance ends.

What remains unproved

This is first-party documentation, not a tested Firefox journey or a performance result. Availability is staged, browser traffic is narrower than device-wide traffic, and essential services have exceptions. No current country census, task success, demand or Mysterium advantage was established.

What would change the conclusion

Compare a legitimate browsing task with the eligible built-in feature, carrying account setup, traffic scope, location and allowance limits. Keep useful interface assistance, separate packaging and a distinctive network advantage as separate questions.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Usage billing · source comparison

A focused job needs a comprehensible bill

What the person does, what gets routed and what gets charged can differ.

Someone buys help for one game session. If unrelated background traffic uses the paid route, or charges arrive after play ends, a successful game can still leave them surprised by the bill.

What we found

Mudfish’s v3 plan documentation counts a 5 GiB download as 10 GiB of relay traffic and permits negative credit balances. In the inspected public Mysterium node code, the calculator instead sums one peer’s sent and received counters. Four upstream calculator tests passed; the provider and consumer totals are not added together.

What remains unproved

Provider documentation is not a runtime billing test; Mudfish’s older plan pages also conflict. The public node code is not a verified charging contract for today’s consumer VPN or GoProxies. Neither source establishes a cheaper service, exact application allowance or customer preference.

What would change the conclusion

A useful comparison would hold the legitimate task constant and test whether people can predict the final charge. Compare usage credit with predictable fixed access; a proposed session cap must cover late charges and preserve required protection. Feasibility, economics and preference remain unmeasured.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Owned video · controlled browser experiment

Resuming quickly can still interrupt the picture

The recovery action has its own effect on the task.

A video player can save your position, reopen and continue quickly. In our controlled test, two reopen sequences nevertheless reported the opening frame before returning near the saved position.

What we found

Eighteen loopback trials compared waiting, replacing the remaining media delivery, and reopening the player. Both mirror actions helped under imposed delays. Two of four delayed reopen trials reported an opening-frame callback; none of the four corresponding in-place replacements recorded a backward frame-time step.

What remains unproved

This used tiny generated video and an immediately available identical mirror. Frame callbacks are not a screen recording or a human visibility judgment. No customer benefit, arbitrary-service integration or Mysterium behavior is established.

What would change the conclusion

Measure presentation during recovery as well as time to resume. A permitted real player and its control surface must establish which remedies are actually available.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Owned video · controlled follow-up

A backup can make the interruption longer

Keep the original transfer until there is evidence to replace it.

A stalled request may still finish before its backup. In the slower-mirror experiment, abandoning the original request added about 1.77 seconds to reaching the four-second playhead target.

What we found

A separate 12-case comparison kept both transfers pending and accepted the first complete body. With the immediate mirror it reached the target 220–227 ms sooner than waiting. With the slow mirror it finished only 5.5–7.5 ms later than waiting, while abort-and-switch was about 1.79 seconds later.

What remains unproved

One Mac, generated video, loopback transfers and two technical repetitions per condition. The server cancels timers before writing a losing body; there is no shared bandwidth queue. Extra requests, real network costs and customer benefit remain unresolved.

What would change the conclusion

Test whether an available remedy preserves the task and whether its extra work competes for the constrained resource. This fixture does not authorize applying duplicate transfers to arbitrary services.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Actual QUIC implementation · simulated packet delivery

A faster reply can still lose the activity

Preserving existing work and starting again are different outcomes.

An established connection survives an address change and continues its existing stream. A fresh connection can also return a reply, but that alone does not bring the previous activity with it. The shortest timer cannot decide which outcome the person wants.

What we found

An aioquic fixture continued the same stream without a new handshake after a simulated address change. Without packet loss, its echo took about one prescribed round trip. Dropping the first outgoing datagram changed the delay substantially; in some constructed cases a cold connection replied sooner. All eight scenarios delivered an echo across three timer settings.

What remains unproved

These are eight constructed scenarios executed 24 times, not field samples. They use real protocol code with in-memory packet delivery, a tiny echo and no VPN, media player or Internet traffic. Cold and established connections have different timing histories. Neither the timings nor the byte counts establish customer benefit, preparation cost or a universal winner.

What would change the conclusion

A useful learner may need to predict whether recovery will exceed the activity’s tolerance, rather than simply predict a connection problem. Identify a concrete preparation action and the stage it can shorten; compare it with competent ordinary recovery while preserving the same task and constraints.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

WireGuard protocol code · in-memory execution

A moving counter can still mean no useful delivery

Measure the meaning of the signal before teaching a system to act on it.

The tunnel exchanges a maintenance message and its byte counter rises. No inner IP packet reaches either test endpoint. A future learner rewarded for counter growth could congratulate itself for doing maintenance while the person’s task remains unresolved.

32 bytesAdded to the receiver’s counter by an additional keepalive in the in-memory test
0 packetsInner IP packets delivered during that maintenance-only stage

What we found

In one staged test of the declared WireGuard implementation, a keepalive added 32 received bytes with zero inner packets delivered. A positive control then delivered one exact 32-byte IP packet and added 64 counted bytes. The protocol counts maintenance and overhead as well as inner traffic. Accurate timing does not make this an activity-progress measurement.

What remains unproved

This ran actual protocol code over in-memory channels, with no system tunnel, external network or installed VPN. It does not establish a customer failure or correspondence to the shipped binary. The positive control was an IP packet, not a film, call or game. Unchanged counters are ambiguous too: the app may simply have nothing to send.

What would change the conclusion

Use counters and handshake time as scoped network observations. Evaluate recovery against the intended task, or a clearly narrower network objective. Keep evaluation access separate from runtime requirements: proving a benefit does not imply continuously inspecting every user’s player.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Responsive TCP · controlled network model

Faster small packets can come with a cost

Measure the whole episode, including the other work sharing the connection.

A model gave small packets quicker passage through a busy queue. During the steady period, the bulk transfer looked almost unchanged. Across the whole run, however, one configuration delivered fewer bulk bytes. The choice depends on the jobs being served, not one attractive average.

What we found

In the prespecified 5–20 second window, Cubic’s small-packet 95th-percentile delay was 15.307 ms with separate flows and 27.901 ms when flows were grouped. Whole-run bulk delivery was 9.31% lower with separate flows, concentrated in startup. NewReno’s whole-run difference was much smaller. The light-load controls had identical packet timings.

What remains unproved

Eight deterministic ns-3 cases modeled TCP feedback, queues and acknowledgments. Grouping was an abstract classifier, not encryption or a real VPN. No person’s activity, fairness preference or field incidence was measured. The native source map identifies possible control points but does not establish control of the actual bottleneck.

What would change the conclusion

Keep startup, steady operation, concurrent tasks and resource cost in the evaluation. A candidate must improve the intended experience where it can actually act. Neither the scheduling result nor the trade-off establishes that personalization or AI is necessary.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Gaming · historical interface counterexample

The indicator can suggest the wrong problem

A measurement, its meaning and a reason to intervene are different things.

A worse-looking network indicator can result from changing what it counts. A smoother game can also come from extra buffering that adds delay. Neither number alone tells the whole story.

What we found

Valve reports that a CS2 indicator revision led some players to infer newly introduced packet loss. It could also flag jitter already absorbed by buffering. Valve then changed the readout to reflect missed game updates caused by network problems.

What remains unproved

This is a historical developer account, not a controlled usability study. The same release included networking fixes. It does not prove every complaint was mistaken or that a new interface improved retention.

What would change the conclusion

Compare interpretation and action against the actual task state. Include the remedies already inside the game, and preserve any buffering-versus-latency tradeoff.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Provider documentation · historical study

Whose connection does the warning describe?

Participant, direction and media matter before choosing a remedy.

You might hear everyone clearly while nobody can hear you. A local “sound received” success label would miss that failure. A warning about another person’s outgoing video cannot, by itself, diagnose your local VPN.

What we found

Zoom documents its participant bar as remote video-uplink information. Google Meet documents an issue dot that appears for five minutes or until opened, at most once a day even if trouble persists. A 2021 controlled study also found that pinning a sender’s video could increase that sender’s traffic.

What remains unproved

The warning meanings come from documentation; the traffic study used historical app versions. Neither is a current Mysterium or call-recovery test. An alert disappearing is not a fresh measurement of recovery.

What would change the conclusion

Observe the required outcome at the affected receiving endpoint. Preserve who sends what to whom and account for viewing-layout changes before attributing an improvement to a network action.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Streaming · historical field experiment

More updating did not mean better results

Check the learning benefit and who actually experiences the gain.

A system can make predictions, improve a technical average and still leave important questions unanswered: did more people get started, did their task improve, and did the latest update help?

What we found

In Puffer’s reported comparisons, daily retraining did not outperform older models. Its mean viewing-duration advantage was driven by sessions longer than three hours; the main playback comparison included only eligible streams.

What remains unproved

These findings concern one historical streaming system. They do not show that all updates are unnecessary, that typical users stayed longer, or that machine learning belongs in an MN product.

What would change the conclusion

Evaluate the prediction, the action and the task separately. Keep failed starts visible and require evidence that updating improves the intended outcome.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Public playback traces · offline prediction

More than half the warning outcomes stayed unknown

Measure outcomes where the proposed action would occur.

A playback monitor can have high overall coverage while losing sight of the cases that trigger its warnings. Counting only the outcomes still visible can give an incomplete picture of the feature.

What we found

Across two fixed Puffer trace days, 97.0% and 96.7% of eligible prediction windows were evaluable. For warnings at the primary buffer-below-two-seconds rule, only 49.0% and 46.4% were evaluable. Within that subset, 48.8% and 32.1% preceded a reported stall.

What remains unproved

These are public playback traces, not Mysterium customer observations. Missing outcomes remain unknown. The analysis does not identify a VPN cause, prove that a warning helps, or supply a real-time way to know which future labels will be missing.

What would change the conclusion

A proposed action needs outcome observation for its triggered population, including false warnings and unknowns. More dates or tuning these same thresholds would not establish that an intervention helps.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Same public traces · first and repeat warnings

The first warning was much less predictive

Evaluate the first proposed intervention separately.

A single average can hide differences between the first time a feature acts and its later actions. Here, those groups also differed sharply in how often their outcomes could be observed.

What we found

In the same two days, only 7.4% and 5.3% of evaluable first warnings preceded a recorded stall within ten seconds. For repeats, the figures were 88.7% and 77.0%. Most warned streams received just one rule-generated warning. The original prediction rule and labels stayed unchanged.

What remains unproved

Roughly two-thirds of first-warning outcomes were unknown, versus under 2% of repeat outcomes. First means first within the captured stream record, not a person’s first-ever warning. These are public traces, not MN customers; no alerts were delivered and no intervention benefit or annoyance was measured.

What would change the conclusion

Keep first and repeat interventions, observation coverage and task outcomes separate. Suppressing every repeat would retain the weaker-looking first-warning group in these records; this is not evidence that showing repeats would help. The cause of the split and the time available to act remain unresolved.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Same two public trace days · separate timing analysis

A correct warning may leave too little time

A prediction must arrive early enough for the proposed action.

Imagine an action that takes two seconds. A correct warning arriving less than a second before the reported stall cannot give that server-triggered action enough time to finish first. Two seconds is an illustration, not a measured VPN response time.

What we found

Correct primary warnings had median intervals of 0.935 and 0.937 seconds between server reports. Only 9.6% and 15.0% left more than two seconds. Among all evaluable warnings, only 4.7% and 4.8% were both correct and above that duration. All original prediction results stayed unchanged.

What remains unproved

Report-to-report time is an optimistic upper bound for an action triggered at the server: reporting and delivery delays can consume part of it. A local app could observe state earlier. Actual action latency and benefit were not measured; more time does not prove an action would help.

What would change the conclusion

Test the timing and outcome of a specified action while preserving the user’s requirements. Preventing a stall and helping someone recover after a visible failure are different promises; neither follows from prediction accuracy alone.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Published artifact · calculation finding

A worse latency input can earn a higher score

A reconstructed calculation, not measured user performance.

Imagine every input stays fixed except latency. Crossing from 999 to 1000 changes the reconstructed total from 2.1 to 2.5 because a later default replaces the zero latency component.

999 → 1000Latency input; selected contracts support milliseconds
2.1 → 2.5Reconstructed total with other components fixed

What we found

All 10,520 retained scores fit one of the predeclared calculation branches. Removing the high-latency fallback loses 62 high-latency matches. Opposing static review accepted the bounded assessment.

What remains unproved

This does not bind an exact deployed build, reveal hidden flags, establish current routing behavior or quantify customer harm. Multiple branches are allowed by the reconstruction.

What would change the conclusion

All seven scheduled registry rounds are complete. Further progress on this claim needs new runtime or response-field correspondence before proposing a production repair; repeating the frozen calculation supplies no such evidence.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Fixed observation · counterevidence

An alarming example became a small measured difference

The IP-quality window hypothesis lost strength.

A toy example showed how choosing a best value instead of the latest value could look misleading. Measuring that difference in one retained window made its magnitude much smaller.

What we found

The below-20 classification changed for 35 of 76,742 metric series: a 0.0456 percentage-point difference in the fixed 24-hour comparison.

What remains unproved

That finding concerns this metric and window. It does not dismiss the separate bandwidth-window effect or establish how either summary affects customer routing.

What would change the conclusion

Keep the smaller observed result. Do not recycle the dramatic toy example as evidence of a large business problem.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Retained workbook · source reconciliation

LTV continues beyond the summary tab

Related reporting locations need a defined relationship.

The company-summary LTV cells stop after week 14. The same workbook contains later values for all-users and paid-users LTV on its product tab. A blank summary alone cannot establish that the metric disappeared.

What we found

Across weeks 15–36, the product tab contains 44 numeric LTV entries while the corresponding 22 company-summary cells are blank. A separate alleged nineteen-week variance failure is contradicted by the actual formulas. Recorded error and spend totals do reproduce.

What remains unproved

The LTV definitions, calculation methods, worksheet-to-warehouse binding and use in decisions remain unvalidated. Broken cells do not establish organizational neglect, and a churn/revenue division does not by itself measure earnings lost.

What would change the conclusion

Resolve the intended relationship between the series and their definitions before substituting values or turning snapshot defects into business priorities. Keep verified cell evidence separate from an explanation of how people worked.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

VPN warehouse · aggregate reconciliation

Most of the refund gap falls outside the shared dates

Compare equal periods before deciding which source is wrong.

One source contains April refunds through the 27th; the other also contains April 28–30. Comparing their whole-month totals makes the difference much larger than comparing the dates both cover.

What we found

A live daily aggregate query places 86.89% of the full-month amount difference on April 28–30. Restricting both sources to April 1–27 reduces the amount ratio from 5.65× to 1.61×, leaving 126 rows and amount_usd 2,944.28 unexplained.

What remains unproved

Exact copies cannot explain most of the shared-date row gap: the retained daily counts require a difference of 119–131 rows even after removing all possible identical copies. This does not bound the amount difference or establish which source is correct. The creation-log lookup was denied; producer definitions remain unresolved.

What would change the conclusion

Resolve the source definitions and ingestion cutoffs before attributing an error or retiring a data source. Keep the unmatched dates and null-date populations visible.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Seven-day research · still active

Seven registry rounds are recorded; the research continues

The fixed observation is finished. The seven-day investigation remains active.

The final direct queries returned 19 of the same 20 selected provider/service keys. That records registry membership at sampled moments; it does not tell us whether a customer could connect or keep the same exit address.

What we found

All seven rounds and 82 planned HTTP requests are retained. Direct forms returned 20, 20, 20, 19, 20, 20 and 19 keys. In the final round, identical US-residential list requests returned 964 and 959 keys with only 98 shared. Every usable score in nine proposal responses fit an allowed frozen calculation candidate.

What remains unproved

The panel is selected, not representative. Registry return is not uptime, persistent egress or household independence. Calculation compatibility does not identify the deployed build or prove fresh measurement. This page is a dated selection, not a live dashboard.

What would change the conclusion

The research window ends September 14 at 06:43 UTC. Continue distinct evidence-backed questions and carry supported findings, rejected stories, useful artifacts and unresolved tests into the final synthesis.

Inspect the sources

Research notes are links into Lee’s Obsidian vault: they open only where that vault is installed, not as web pages. The source snapshot records their hashes; later edits do not update this dated view automatically.

Scope and source record

A private research selection, with traceable inputs.

Prepared for the Kairos team. Kairos operates this private research; MN owns customer access, data, product decisions, merge and release. Online, the page opens for everyone who signs in to the Kairos War Room, the MN team included. It does not operate a VPN, change settings, contact customers or publish findings.

The source record distinguishes reported behavior, a product hypothesis, a reconstructed calculation and a fixed-window observation. Commercial benefit, installed-build correspondence and task-level advantage remain unresolved. The underlying notes provide the detailed methods and counterevidence.

Open the source snapshot (JSON) · Open the separate interaction prototype