Trust & Legal

Providers

Every external service Rootlynq contacts, when, and what it can see. Generated from the audited data-flow inventory.

Lovable (application hosting)

Hostname: rootlynq.com (Lovable-hosted site)
Service: Application hosting and content delivery
Purpose: Serve the Rootlynq application
Trigger: Opening any page
Data involved: Ordinary request metadata: IP address, user agent, requested URL, timestamps
Destination: Lovable hosting infrastructure
Retention: Lovable privacy policy and workspace settings
Privacy policy: https://lovable.dev/privacy

Google Identity Services

Hostname: accounts.google.com
Service: Google OAuth sign-in for Rootlynq accounts
Purpose: Let customers create and sign in to a Rootlynq account before using Helios without Rootlynq handling their Google password.
Trigger: Only after the customer selects Continue with Google on the Account page.
Data involved: Google processes its own sign-in session and receives the OAuth client and redirect request. With customer authorization, Google provides account identifier, name, email address and profile image to Supabase Auth. Rootlynq does not receive the Google password.
Destination: Google Identity Services, then Supabase Auth
Retention: Google account and privacy settings; Supabase Auth stores the resulting Rootlynq account identity and session records.
Privacy policy: https://policies.google.com/privacy

Supabase Auth

Hostname: esbvjvsaoroqbeuldrpz.supabase.co
Service: Rootlynq account sessions and account-gated Helios access
Purpose: Verify a signed-in Rootlynq customer before accepting a Helios text or voice request. A server-only paid-tier switch can later require a verified subscription.
Trigger: After Google sign-in; when the Account or Resolve page checks status; and before each Helios request.
Data involved: Supabase stores the account identifier, email, Google identity information and authentication sessions. Rootlynq sends the session token to Supabase Auth for verification. No Rootlynq diagnostic report, precise device location or raw network identifier is stored in the account.
Destination: Rootlynq's dedicated Supabase project
Retention: Supabase Auth and project retention settings; customer may request account deletion through Rootlynq support.
Privacy policy: https://supabase.com/privacy

Stripe

Hostname: checkout.stripe.com; billing.stripe.com; api.stripe.com (server-to-server)
Service: Optional Rootlynq Supporter checkout, recurring billing and customer portal
Purpose: Let a signed-in customer optionally support Rootlynq for $20 per month while Helios remains free with an account.
Trigger: Only when a signed-in customer selects Become a Supporter or Manage billing; Stripe also sends signed subscription and invoice webhooks after a purchase.
Data involved: Rootlynq sends the customer's account ID and email to Stripe to create a customer and checkout session. Stripe collects and processes payment details on its hosted pages. Rootlynq stores the Stripe customer and subscription IDs, status, payment verification state and period end in its dedicated Supabase project. No diagnostic report, precise device location or raw network identifier is sent with billing requests.
Destination: Stripe; Rootlynq's dedicated Supabase project for subscription status
Retention: Stripe privacy policy and billing retention rules; Supabase project retention settings. Cancellation is available through the Rootlynq account billing portal.
Privacy policy: https://stripe.com/privacy

Browser / device Location Services

Hostname: Browser API (no Rootlynq network destination)
Service: Optional browser geolocation requested when the Test page opens with location details enabled. Browser or OS permission is required.
Purpose: Provide the browser's device position for the active page so Rootlynq can distinguish physical test location from an IP relay, VPN, carrier gateway, or ISP egress location.
Trigger: When the Test page opens with location details enabled, or when the user presses Show device city to retry. Browser permission is required.
Data involved: Precise latitude, longitude and browser-reported accuracy stay only in page memory. Before any city-label network request is created, the browser rounds latitude/longitude to two decimal places (roughly city scale). Precise coordinates are never written to reports, local/session storage, exports, Cloudflare metadata requests, OpenStreetMap requests, or Helios evidence.
Destination: Precise coordinates: page memory only. A separately derived two-decimal rounded point may be sent to Rootlynq's same-origin city-label endpoint after browser permission is granted; the server uses the configured geocoder.
Retention: Precise coordinates: Rootlynq page memory only
Privacy policy: /privacy

Geoapify Reverse Geocoding API (when server key is configured)

Hostname: api.geoapify.com (server-to-server from Rootlynq)
Service: Hosted reverse geocoding of a browser-rounded two-decimal point into a city/region label.
Purpose: Provide scalable device-city labels while keeping the Geoapify API key and precise browser coordinates off the client and outside Helios.
Trigger: After browser device-location permission is granted on Test and only when ROOTLYNQ_GEOAPIFY_API_KEY is configured server-side. A failed hosted lookup does not fall back to public Nominatim.
Data involved: Geoapify receives only latitude/longitude rounded in the browser to two decimals, plus Rootlynq's server request metadata and API key. Precise browser coordinates and the visitor's direct IP are not forwarded. Rootlynq keeps the city label only in page memory and an in-memory 24-hour server cache; it is excluded from reports and Helios evidence.
Destination: Geoapify via Rootlynq server
Retention: Geoapify privacy policy states successful API request data is generally kept no longer than 24 hours; Rootlynq keeps a 24-hour in-memory cache by rounded cell.
Privacy policy: https://www.geoapify.com/privacy-policy/

OpenStreetMap Foundation Nominatim

Hostname: probe.rootlynq.com (Rootlynq Fly probe); nominatim.openstreetmap.org (server-to-server from Fly)
Service: Fallback reverse geocoding of a browser-rounded two-decimal point into a human-readable city/region label when no hosted provider key is configured.
Purpose: Display a city/state or equivalent locality label without exposing the browser's precise device coordinates to the geocoder.
Trigger: After browser device-location permission is granted and only when the Geoapify server key is not configured, or after an explicit Retry city lookup in that configuration.
Data involved: Only latitude/longitude rounded to two decimal places (roughly city scale) is forwarded from Rootlynq's Lovable server to its single Fly probe and then to Nominatim. The precise browser coordinates never leave the page. Fly and OpenStreetMap see Rootlynq server request metadata, not the browser's direct geolocation request or visitor IP. Rootlynq returns only the human-readable locality label to the page and does not save it in reports or send it to Helios. The Fly probe serializes uncached public Nominatim requests to at most one per second.
Destination: Rootlynq Fly probe, then OpenStreetMap Foundation Nominatim
Retention: OpenStreetMap Foundation privacy policy; Rootlynq's Lovable server and Fly probe keep successful labels in separate in-memory 24-hour caches by rounded cell.
Privacy policy: https://osmfoundation.org/wiki/Privacy_Policy

Rootlynq hosting edge + IANA/RIR RDAP + RDAP.org fallback

Hostname: rootlynq.com; data.iana.org; authoritative Regional Internet Registry RDAP endpoint; rdap.org (fallback bootstrap only)
Service: Same-origin endpoint reads the hosting edge's trusted client-IP header after Start. For a non-relay address, the server uses the IANA RDAP bootstrap file to select the authoritative Regional Internet Registry and retrieves the registered network organization/name. If that standards path is temporarily unavailable, Rootlynq may use RDAP.org only as a bootstrap fallback; RDAP.org redirects the query to the authoritative registry.
Purpose: Show the public IP and registered network/provider visible to Rootlynq independently from the Cloudflare speed-test path. Known Cloudflare Private Relay addresses are labeled locally; Rootlynq offers Safari's supported per-site Show IP Address workflow instead of bypassing privacy protections.
Trigger: Only after the user starts a Test or explicitly refreshes the network identity card.
Data involved: The public IP already present in the HTTPS request is returned to the active page for display. For non-relay addresses, that IP is used in a server-to-server RDAP lookup via the IANA-selected authoritative RIR; if that path is unavailable, the same IP may be sent to RDAP.org as a bootstrap fallback and then redirected to the authoritative registry. Rootlynq never writes the full/partial IP, ASN or device-location label into saved/exported reports or Helios evidence. A coarse registered provider/network organization may be retained in the session-scoped active case and forwarded to Helios for provider-aware diagnosis.
Destination: Rootlynq application server; IANA RDAP bootstrap; authoritative Regional Internet Registry; RDAP.org only as fallback bootstrap
Retention: Rootlynq keeps the full IP only in page memory and may keep short-lived in-memory caches of bootstrap/RDAP organization results. The active browser session may retain only the coarse provider/network organization for the current diagnostic case. RDAP.org states that individual queries are not logged, while Cloudflare may aggregate source IP data for rate limiting; registry operators apply their own policies.
Privacy policy: https://about.rdap.org/

Cloudflare Speed Test

Hostname: speed.cloudflare.com
Service: Cloudflare Speed Test metadata endpoint (/meta) plus same-host trace metadata, returning the Internet-facing client IP, ASN/provider organization, edge colo, approximate IP-derived city/region/country, and WARP state when exposed by trace.
Purpose: Describe the address/path visible to the Cloudflare measurement service, including relay/proxy state and the selected Cloudflare test location. This remains separate from Rootlynq's same-origin direct-network identity.
Trigger: When the Test page opens, to show the measurement node before Start, and again when the user starts a connection test, Retest, Verify fix, or an explicit diagnostic comparison.
Data involved: Connecting address and ordinary request metadata. Cloudflare can return provider/ASN and approximate IP-derived location for the path it sees; with Safari Private Relay this can be a relay egress rather than the subscriber network. Full/partial IP, ASN and IP-derived location stay page-memory-only and are excluded from reports and Helios evidence. When no privacy relay is detected, the coarse provider organization may be copied into the session-scoped Helios network context.
Destination: Cloudflare
Retention: Cloudflare privacy policy
Privacy policy: https://www.cloudflare.com/privacypolicy/

Cloudflare measurement transport

Hostname: speed.cloudflare.com
Service: Rootlynq clean-room browser capacity engine using bounded adaptive concurrent transfers against Cloudflare's documented /__down and /__up measurement transport, plus Rootlynq-owned latency, jitter and loaded-latency sampling. Cloudflare's JavaScript speed-test SDK is not used for the primary capacity result.
Purpose: Measure idle response/jitter, aggregate download/upload capacity and response while busy. The single Start test can grow to eight concurrent workers; Single keeps one transfer worker. Response lasts eight seconds; download and upload last eight or twelve seconds according to a pre-phase pilot. Incomplete phases do not produce a normal speed result.
Trigger: Only after the user starts the connection test, Retest, Verify fix, or an explicit diagnostic comparison.
Data involved: Connecting network address, request metadata and bounded measurement traffic (one connection test capped at 4 GB per throughput direction, about 8 GB combined plus small setup probes; slower links use less; optional Deep Diagnosis may add about 30 MB). Rootlynq does not post the primary measurement result to Cloudflare measurement-result or AIM logging APIs.
Destination: Cloudflare
Retention: Cloudflare privacy policy
Privacy policy: https://www.cloudflare.com/privacypolicy/

Rootlynq measurement node on Fly.io

Hostname: dfw.measure.rootlynq.com, ord.measure.rootlynq.com, iad.measure.rootlynq.com, lax.measure.rootlynq.com, sjc.measure.rootlynq.com, ewr.measure.rootlynq.com (only after per-region capacity certification and operator activation; DNS-only aliases to Fly.io)
Service: Independent bounded download/upload transports in Dallas, Chicago, Ashburn, Los Angeles, San Jose and Secaucus, each with a region-bound short-lived signed session, per-session byte ceiling and receipt-verified upload
Purpose: Provide a second network path for the same one-button speed test when its server capacity has been independently verified. The node contributes to the headline only when the configured capacity gate and live pilot both pass.
Trigger: Only after the user starts Standard mode and the operator has enabled a certified measurement node.
Data involved: The node receives the connecting network address, ordinary HTTPS request metadata, short-lived bearer token and bounded test payload. The signed token does not include the user's IP, device identifier, location, or report ID. Up to 8 GB combined main-transfer payload is shared across all speed-test transports, never granted per node.
Destination: Rootlynq's Fly.io measurement services in Dallas, Texas; Chicago, Illinois; Ashburn, Virginia; Los Angeles and San Jose, California; and Secaucus, New Jersey. Only the selected eligible node receives main transfer traffic.
Retention: The service keeps only a short-lived in-memory byte counter keyed by random token nonce; ordinary Fly.io operational logs and policies apply.
Privacy policy: https://fly.io/legal/privacy-policy/

Hexium Helios

Hostname: hexium-ai-production.austin-d-gomez-mil.workers.dev (server-to-server from Rootlynq); api.openai.com (server-to-server from Hexium for governed public-web research/model reasoning)
Service: Governed Rootlynq technician conversation, diagnostic reasoning, mandatory current public-web research and shadow measurement planning
Purpose: Let customers talk to Helios before or after testing, combine Rootlynq measurements and customer context with current provider/standards research, guide troubleshooting, and compare Helios's bounded server/duration advice with the deterministic Test plan. The shadow advice cannot alter measured speed.
Trigger: After the user explicitly starts a Standard Test, a sanitized measurement-plan request may be sent. Resolve contacts Helios after a signed-in customer sends a technician message; a Test is not required before conversation starts. Helios can propose an allowed check, which runs only after customer approval.
Data involved: For measurement planning: only approved server IDs/network labels, pilot throughput and timing, and the shared byte budget; no client IP, ASN, ISP, device location or identifiers are in that shadow-planning payload. Diagnostic reasoning/Resolve may send the user's bounded message, recent transcript and sanitized case evidence to Hexium, including user-reported troubleshooting context, a bounded hypothesis/case-brain state, local temporal metric summaries, optional Network Watch summary, plus a coarse registered provider/network organization and browser-reported connection type. When a signed-in customer pairs Rootlynq for Windows, Resolve may additionally send schema-bounded client-reported native evidence: adapter connection state, Windows Wi-Fi link quality when available, local-gateway ICMP observation, OS name-resolution state, direct TCP reachability, PC manufacturer/model, and a gateway manufacturer/model only when advertised through the read-only discovery path. possibleVpnPresent is heuristic evidence and ONT telemetry remains explicitly unavailable. User-reported context is not measured telemetry. Full/partial public IP, ASN, SSID, BSSID, MAC or local IP, gateway/DNS addresses, precise or city-level location, report ID, TURN credentials, raw ICE candidates, passwords, account numbers, serial numbers and raw device identifiers are excluded. Before each diagnostic turn Hexium creates a separate sanitized public-web research query from non-identifying measurements, structured symptom/timing context, allowlisted privacy-safe reported signals, coarse provider context and allowlisted diagnostic topics; raw transcript text and network identifiers are not sent to the web-search query.
Destination: Canonical Hexium Helios production Worker; governed model/web-search provider for the sanitized research query and final reasoning
Retention: Rootlynq keeps the active technician transcript in browser session storage rather than a Rootlynq cloud report database. Server-to-server Helios/provider processing follows the Hexium AI runtime policy.
Privacy policy: https://hexorium.io/privacy

OpenAI GPT Live through Hexium Helios

Hostname: api.openai.com (WebRTC media from browser; session creation from Hexium production Worker)
Service: Optional live voice conversation with the Helios technician on Resolve
Purpose: Let the customer speak with Helios about their symptoms and sanitized Rootlynq results, with spoken replies and an optional transcript.
Trigger: Only after a signed-in customer presses Talk to Helios and grants browser microphone permission. A Test is not required.
Data involved: OpenAI receives microphone audio and ordinary WebRTC connection metadata, including the connecting network address, while the call is active. Hexium sends recent customer/Helios transcript text and sanitized case evidence as session context; Rootlynq excludes precise location, full public IP, Wi-Fi identifiers, raw ICE candidates and device identifiers from that evidence. Generated speech returns on the media track. Rootlynq keeps text transcript turns in browser session storage. The call requests store:false; OpenAI may still retain abuse monitoring data under its API data controls.
Destination: OpenAI GPT Live, governed and created by the Hexium production Worker
Retention: Rootlynq browser session storage for text turns; OpenAI API data controls for provider-side processing and abuse monitoring. No Rootlynq audio recording is requested.
Privacy policy: https://developers.openai.com/api/docs/guides/your-data

Rootlynq first-party probe aliases

Hostname: rootlynq.com, probe.rootlynq.com, v4.rootlynq.com and v6.rootlynq.com
Service: First-party HTTPS timing paths: same-origin responsiveness used by Deep Diagnosis and consented Network Watch, plus a fresh-origin setup probe and A-only/AAAA-only family reachability probes
Purpose: Measure Rootlynq web response behavior, allow a short consented series of lightweight same-origin responsiveness samples for intermittent problems, expose DNS/TCP/TLS setup only when a fresh first-party connection is observable, and compare IPv4/IPv6 HTTPS reachability when family-specific aliases are configured
Trigger: Only when the user explicitly runs Deep Diagnosis or approves Helios' lightweight Network Watch after a standard diagnosis
Data involved: Ordinary HTTPS request metadata to Rootlynq hosting. Deep Diagnosis retains bounded timing/status evidence. Network Watch retains only a bounded summary of first-party HTTPS response timing, request failures and page-visibility interruption; failed HTTP requests are not labeled packet loss. Probe hostnames and raw timing samples are excluded from the Helios evidence bundle.
Destination: Rootlynq/Lovable hosting through first-party family-specific aliases
Retention: Same hosting policy as rootlynq.com
Privacy policy: https://rootlynq.com/privacy

Cloudflare Calls TURN via Hexium credential broker

Hostname: turn.cloudflare.com / stun.cloudflare.com (short-lived ICE session)
Service: Optional TURN-based UDP packet-loss measurement plus relayed synthetic WebRTC quality measurement
Purpose: Measure TURN round-trip UDP packet loss and, separately, jitter and WebRTC round-trip time on a silent synthetic audio path without microphone or camera access
Trigger: Only when the user explicitly runs the Real-time quality test, or accepts Helios' rtc_probe next-test action
Data involved: TURN connection metadata, purpose-built UDP probe traffic, and synthetic RTP traffic. Rootlynq sends no microphone, camera, SSID/BSSID, precise location, report ID, TURN credential, or raw ICE candidate inside the Helios evidence payload. The TURN provider necessarily observes the network address used to establish the relay.
Destination: Cloudflare Calls TURN; short-lived ICE credentials are generated server-side by the Hexium production Worker
Retention: Cloudflare Calls and Hexium operational policies apply; Rootlynq does not persist TURN credentials or raw WebRTC stats beyond the active page session
Privacy policy: https://www.cloudflare.com/privacypolicy/

Not contacted

ipwho.is and commercial IP-geolocation/ISP lookup services (not used)
fonts.googleapis.com / fonts.gstatic.com (removed; system fonts only)
Advertising or analytics services (none)
Any device-location request when the user has switched location details off (never)

The Lovable editor preview may inject its own development scripts; those are not part of Rootlynq's production diagnostic data flow.