Privacy Policy

1. Effective date

This policy is effective as of August 13, 2026, the date it was last updated. We may revise it from time to time; see the Changes section below.

2. Information we collect

Axlyne is built local-first: vehicle profiles, scans, trips, and adapter records stay on your device unless you export and share them. A fresh installation starts signed out. The current app does not create an anonymous session automatically. The production app sends account and subscription identifiers after optional account creation or sign-in. An existing installation may continue authenticating a legacy anonymous session created by an earlier release. The categories below describe everything the app may handle.

Account data: if you choose to create an account or sign in with email and password, Google, or Apple, Supabase assigns or returns an account user ID and authentication session credentials that the app stores in protected storage on your device. Once you are signed in with email, Google, or Apple, the app sends that account user ID to RevenueCat to check, purchase, or restore Axlyne Pro. Existing installations may retain a legacy anonymous Supabase session created by an earlier release. The current app does not create a new anonymous session automatically. Vehicle profiles, scans, trips, and adapters do not leave your device for account backup. No saved-record copy leaves the device for AI processing in this candidate.

Account-export security counter: after a signed-in user requests an account-data export, the app backend stores the existing account user ID with the export-data endpoint bucket, UTC day window, and request count. The app endpoint does not write the request IP address or user agent to the Axlyne application database. We use the counter only to limit abuse, not for advertising, analytics, or tracking.

Account agreement records: when you accept the current Terms and Privacy Policy while signed out or in a legacy anonymous session, Axlyne stores a device-only guest receipt. If you later sign in with a non-anonymous account, Axlyne automatically creates a new receipt linked to that account from the current guest receipt. It preserves the original device-reported acceptance time, exact document revision and SHA-256 hashes, platform, and app version; assigns a new random receipt ID; queues it locally, and sends it to Supabase. Supabase stores the signed-in account user ID with that receipt and the server receipt time. The original guest receipt stays on the installation. Acceptance while already signed in uses the same account-linked receipt and Supabase delivery path.

Optional sign-in data: if you choose email and password, Google, or Apple sign-in, Supabase processes the identifiers and authentication data needed for that method. Google sign-in requests OpenID, email, and basic profile information. Apple sign-in may provide your email and name according to your Apple choices. We do not receive your Google or Apple password.

Federated revocation credentials: when you sign in with Apple or Google, Axlyne sends the provider authorization code or provider access and refresh credentials to its backend. The backend validates the credential against the linked provider account and stores only encrypted revocation material linked to your Axlyne account user ID. Axlyne uses this material only to keep the sign-in connection verifiable and to revoke it automatically if you delete your account. Raw provider credentials are not written to Axlyne logs, analytics, support output, or account exports. An account export includes only safe credential metadata: the provider, revocation state, capture and update times, revocation time, and non-secret revocation proof fields.

Vehicle and diagnostic data: vehicle profile details (such as a nickname, year, make, model, and a Vehicle Identification Number if you enter one) and recorded trouble-code identity, reported status, system, and canonical response payloads stored locally from a scan. A physical scan reads a valid 17-character VIN from live Mode 09. If the vehicle profile has no VIN, Axlyne saves that live VIN; if a VIN is already saved, the live VIN must match. Axlyne refuses to save physical evidence when the VIN is missing, invalid, or different. From a replay-verified Mode 01 PID 01 receipt, Axlyne may show the source-reported malfunction-indicator state, confirmed emissions-related DTC count, ignition type, and supported readiness-monitor completion. It does not infer missing data, present freeze-frame observations, or predict an emissions-inspection result. After that VIN-bound physical scan, Axlyne can read and display supported read-only Mode 01 gauge values for that current vehicle, adapter, and connection. The app processes those live values in memory and does not save them in scans or reports. The demo adapter remains clearly labeled and simulated. This release does not send the raw VIN, year, make, or model to NHTSA. Network VIN decoding and NHTSA campaign or complaint lookup are unavailable.

Future optional AI chat data: A future separately authorized, evidence-bound candidate would make AI chat available only after a signed-in Axlyne Pro user reviewed the then-current disclosure and tapped Start chat. The device would send the visible chat thread and a bounded record packet to https://ai.axlyne.com/v1/ai/chat, an Axlyne-managed service that would be hosted on Google Cloud Run behind Cloud Armor. Depending on the question, the packet could include a local scan reference; vehicle year, make, model, and engine; scan time and OBD source; reported trouble codes and statuses; recorded readings and availability; malfunction-indicator, readiness, protocol, responding-module, and on-board-test fields; and user-set maintenance reminders. That future AI flow would not send the VIN, location or mileage-route points, raw or hashed adapter identifiers, or unknown-source scans. The backend would validate the thread and record, reject out-of-scope requests, and classify the current question into a closed intent. It would create a closed non-record selection envelope containing only the intent, language, constant category choices, and allowed layouts. The external model provider would receive no user message, chat prose, vehicle fact, measurement, VIN, identifier, record value, or attachment. It could return only a category order and allowed layout. The Axlyne backend would render every visible answer word and record value from validated typed fields. On a clearly labeled simulated report, a signed-in Pro user could tap Ask Axlyne AI. The app would send the visible message and clearly labeled synthetic demo context only after the user reviewed the separate demo disclosure and tapped Start chat. That context would use the same bounded fields listed above, remain marked as simulated, and contain demo-adapter data, not readings captured from a physical vehicle. The managed service would use the signed-in account ID for access control, per-user rate and token limits, duplicate-request suppression, and a short-lived cache-hit marker. It would write only the bounded Supabase operational records described under Data retention. Cloud Armor would process the source IP only as a transient pre-authentication rate-limit key. The managed transport would not persist the source IP or a derived IP identifier. Google Cloud request logging and caching would be disabled for this route, so Google Cloud would not persist the visible thread, bounded record packet, or rendered answer. The model provider would not receive the Axlyne account ID or source IP.

Future optional AI-answer reports: A future separately authorized, evidence-bound candidate would keep report submission and report review unavailable until a separate moderation service were implemented, approved, deployed, and verified. Public release of that future candidate would remain blocked on that gate. After the gate were satisfied, a signed-in user could tap Report on a displayed AI answer and confirm sending the server-issued aar2 receipt for that exact answer with the fixed reason inaccurate or unsafe. The signed receipt would carry a random server answer ID, account-specific keyed binding, Garage or Scan surface, renderer kind, closed intent, language, layout and category metadata, and issuance and expiry times. Its moderator-encrypted payload would contain the exact displayed answer and its SHA-256 digest. Because the answer could repeat saved vehicle or scan facts already shown on screen, those displayed facts would be part of the encrypted answer. The report would not include the user question, other chat turns, the original record packet, VIN, email address, provider or model name, device data, request address, or free-form report text. Axlyne’s report-ingestion service would verify the server signature, account-specific keyed binding, surface, and receipt lifetime without decrypting the answer. It would store signed metadata and moderator-encrypted ciphertext. Only the separately authorized moderation service would hold access to the private decryption key used for safety and accuracy review. That private key would be unavailable to the app, report-ingestion service, database, and external model providers. The moderator view would omit the account identity, and external model providers would not receive the report.

Connection data: the advertised device name, connection transport, and a one-way hash of the local device identifier. These values stay on your device and are used only to remember a connection. Axlyne does not derive or store an adapter compatibility, clone, quality, capability, or reliability score.

Location data: if you use the GPS mileage and drive-tracking features, the app samples your device location while a trip is being recorded in the foreground in order to calculate distance. We do not collect background location. Location sampling stops when you stop recording.

Local app data: settings and operational state needed to run the app remain on your device. This release does not send product analytics, crash reports, or performance telemetry to us or to an error-monitoring provider.

Purchase data: RevenueCat receives the app account user ID, app-store purchase and product identifiers, subscription status, and entitlement status needed to provide and restore Axlyne Pro. Payment card details are handled by Apple or Google and are never received or stored by us.

3. How we use information

We use each category only for the specific purposes below, and not for unrelated ones.

To provide core features: read bounded generic diagnostic responses, record trouble-code observations, display supported read-only Mode 01 values for a verified connection, show labeled demonstrations, log mileage, and store local history.

To provide identity: process optional account creation or sign-in that you request and keep subscription records associated with the correct signed-in account user ID. For Apple and Google sign-in, retain encrypted provider revocation material so the linked authorization can be verified and revoked when you delete the account.

To operate subscriptions: confirm and restore your entitlement through the app store.

Future optional Axlyne AI chat: A future separately authorized, evidence-bound candidate would summarize facts in saved OBD records, cite those records, and help a user prepare questions for a qualified technician. That future service would not diagnose a fault, rate severity, decide whether a vehicle was safe to drive, recommend a repair, or estimate cost.

Future AI security: A future separately authorized, evidence-bound candidate would use signed-in account counters, bounded AI token budgets, duplicate-request controls, and transient pre-authentication source-IP throttling at Cloud Armor to detect and stop fraud or attacks and enforce our Terms. It would not persist the source IP or a derived IP identifier.

To improve and support the app: respond to information you choose to include in a support request and use release testing performed before distribution.

To meet legal obligations: comply with applicable law and respond to lawful requests.

We do not sell your personal information, and we do not use your vehicle, diagnostic, or location data for advertising or for training artificial-intelligence models. A future separately authorized, evidence-bound candidate would instruct OpenRouter to exclude model providers that collected prompts or responses for training.

4. Service providers and sub-processors

We use a small number of third-party providers to run the app. They process data as needed to provide their service under their applicable agreements and privacy terms. Current categories of providers are:

Backend and authentication: Supabase creates or authenticates an account only when you choose account creation or sign-in. Supabase may also retain a legacy anonymous session created by an earlier release and stores the account records needed for that service. For Apple and Google sign-in, the Axlyne backend stores encrypted provider revocation material linked to the Supabase account user ID until the material is replaced or the authorization and account are deleted.

Subscription management: RevenueCat receives the app account user ID and app-store subscription information needed to validate and manage purchase entitlements and provide subscription dashboard analytics.

Future AI processing and answer reporting: A future separately authorized, evidence-bound candidate would send the consented visible thread and bounded record packet to https://ai.axlyne.com/v1/ai/chat, which Axlyne would run on Google Cloud Run behind Cloud Armor. The managed service would validate, classify, and render the answer. Cloud Armor would process the source IP only as a transient pre-authentication rate-limit key. The managed transport would not persist the source IP or a derived IP identifier. Google Cloud request logging and caching would be disabled for that route, so Google Cloud would not persist the visible thread, bounded record packet, or rendered answer. Supabase would authenticate access and store only the account-linked operational metadata, request hashes, security events, and fixed cache-hit marker described in this policy, not the visible thread, bounded record packet, or rendered answer as cache content. If the separately gated report feature were enabled, Supabase report ingestion would verify an aar2 receipt without decrypting the answer and would store its signed metadata and moderator-encrypted ciphertext. The separate moderation service would have to be implemented, approved, deployed, and verified before report submission, report review, or public release of that candidate. OpenRouter would be the only external model processor enabled for that future candidate. Its code-pinned, allow-listed text models would receive only the closed non-record selection envelope: intent, language, constant category choices, and allowed layouts. Each OpenRouter request would require a zero-data-retention endpoint, deny provider data collection, apply a price ceiling, and limit fallback to the closed model allowlist. The direct GLM route would remain disabled and would require separate approval, deployment, verification, and updated disclosures before use. No external model provider would receive a user message, chat prose, vehicle fact, measurement, VIN, identifier, record value, or attachment. That candidate would not use general-purpose proxying, image, audio, video, OpenAI, or Anthropic models. Users would be told not to include secrets or unrelated personal information in a chat message.

App distribution and billing: Apple and Google, which distribute the app and process all payments for subscriptions.

We may add, remove, or change providers over time. A current list is available on request by emailing axlyne@proton.me. We aim to choose providers that offer appropriate security and contractual data-protection commitments.

5. Legal bases for processing (GDPR)

For users in the European Economic Area, the United Kingdom, and Switzerland, we rely on the following legal bases under the GDPR and equivalent laws.

Performance of a contract: to provide the app and the features you request, including optional account creation, sign-in, and subscription access.

Consent: for optional features that you switch on, such as location-based mileage tracking. A future separately authorized, evidence-bound candidate would also rely on consent for AI chat and a confirmed AI-answer report. You could withdraw that consent by stopping use of the future feature, with no effect on processing already carried out.

Legitimate interests: to secure the app, prevent abuse, and fix defects, balanced against your rights.

Legal obligation: to comply with applicable law and respond to lawful requests.

6. Data retention

On-device data (vehicles, scans, trips, reminders, and logs) is kept on your device until you delete it in the app or uninstall the app. You control it.

Signed-in account data and any legacy anonymous account data are kept while the account is active. Uninstalling the app does not by itself delete the backend account. The release-candidate deletion service records an erasure fence, requests deletion of the RevenueCat customer and verifies provider absence, removes the matched waitlist row, automatically revokes each stored Apple or Google authorization and verifies the revocation, deletes the encrypted provider credential, then removes the Supabase authentication account and linked database rows. Encrypted provider revocation material is retained until it is replaced, its authorization is verified as revoked, or account deletion finishes. Existing federated accounts created before this credential-capture flow must sign in again with each connected provider before deletion can proceed. Axlyne does not treat manual provider-unlink instructions as proof of deletion. Public launch remains blocked until the exact production deployment and signed cross-device tests prove that a stale installation cannot recreate the deleted RevenueCat customer. Apple and Google retain store transaction records under their own policies and applicable law. To prevent deleted subscription customers from being recreated, Axlyne retains a one-way SHA-256 digest of the RevenueCat customer identifier indefinitely as a security and deletion-suppression record. It retains no raw customer identifier, email address, provider token, or purchase record and is not included in the account export. This digest is not user-deletable because removing it would remove the erasure fence. We may retain other limited records when required by law or needed to protect the service from abuse. The account-export security counter is deleted with the account or by a daily cleanup after its UTC window is more than seven (7) days old.

Account-linked agreement receipts, including automatically promoted receipts, remain immutable in Supabase while the account exists, appear in the account-data export, and are deleted when the account is deleted. Device-local agreement receipts, including the original guest receipt and locally stored account copies or pending deliveries, remain on the installation until local app data is deleted or the app is uninstalled.

Location samples used for a trip are retained as part of that trip record under your control on the device, subject to your export and deletion choices.

Future AI retention: A future separately authorized, evidence-bound candidate would not store the assistant response, visible chat thread, or bounded record packet as cache content. New cache rows in that candidate would store only the account user ID, SHA-256 request hash, provider or server-route label, fixed cache_hit_v1 marker, hit count, and creation and expiry times. The hash would be derived from the account user ID, current message, language, classified intent, and complete validated bounded record. Each new row would expire no more than thirty (30) minutes after creation. A scheduled cleanup would run every fifteen (15) minutes to delete expired rows. Unexpired cache rows created before the marker migration would keep their original expiry of no more than thirty (30) minutes and age out without extension. Public release of that future candidate would remain blocked until a signed live readback proved that no plaintext cache response remained. User-linked AI token reservations would retain the account user ID, UTC date, budget bucket, reserved and accounted token counts, completion status, provider label, and request hash. The request hash would block in-progress or completed same-day duplicate requests. AI security events could contain the event type, language, context kind, bounded record counts, turn count, token counts, and allow-listed model identifier. Neither record would contain a request address, chat text, or record value. Token reservations and security events would be deleted after thirty (30) days or when the account was deleted. Account-linked AI rate-limit rows would be deleted after seven (7) days or on account deletion. Cloud Armor would process the source IP only as a transient pre-authentication rate-limit key. The managed transport would not persist the source IP or a derived IP identifier. Google Cloud request logging and caching would be disabled for that route, so Google Cloud would not persist the visible thread, bounded record packet, or rendered answer. Aggregate daily provider and token totals would contain no account ID or chat text.

Future AI report retention: If reporting were enabled after the moderation gate was satisfied for a future separately authorized, evidence-bound candidate, a confirmed AI-answer report would store the account user ID; server-generated report and answer IDs; receipt version; encryption, signing, and subject-key IDs; account-specific subject binding; signed public claims; wrapped content-encryption key; nonce; moderator-encrypted ciphertext; receipt signature; Garage or Scan surface; fixed inaccurate-or-unsafe reason; closed review disposition and corrective-action fields; and creation, review, and expiry times. The encrypted answer could contain saved vehicle or scan facts that were visible in that answer. It would not contain the user question, other chat turns, original record packet, VIN, email, provider, model, device, request-address, or free-form report field. Bounded report identity, rendering, reason, review-state, and lifecycle metadata would appear in the account-data export, but the account-data export would omit the cryptographic envelope. Account deletion would delete the report immediately. Otherwise, it would expire exactly ninety (90) days after creation, and a scheduled cleanup every fifteen (15) minutes would delete expired rows. The separate account-linked report rate-limit row would be deleted with the account or by the existing daily cleanup after its UTC window was more than seven (7) days old.

Backups and logs may persist for a limited additional period before being overwritten in the ordinary course.

7. Your privacy rights

Depending on where you live, you may have some or all of the following rights.

GDPR and UK GDPR: to access, correct, delete, restrict, or object to processing, to data portability, and to withdraw consent. You also have the right to lodge a complaint with your local supervisory authority.

California (CCPA and CPRA): to know what personal information is collected, used, and disclosed; to delete it; to correct it; to opt out of sale or sharing; to limit use of sensitive personal information; and not to be discriminated against for exercising these rights. We do not sell or share personal information as those terms are defined under California law.

Other US states: residents of states with comprehensive privacy laws (including Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Iowa, Delaware, and others as they take effect) have comparable rights to access, correct, delete, obtain a portable copy of, and opt out of certain processing of their personal data.

We will not discriminate against you for exercising any of these rights.

8. How to exercise your rights

To exercise any right, email axlyne@proton.me from the email address associated with your request, and describe what you would like to do. Much of your data can also be deleted directly in the app through the Your Data screen.

We will respond within the time required by applicable law and may verify your identity before acting. You may use an authorized agent where the law allows.

9. Children

Axlyne is intended only for adults who are at least 18 years old and have reached the age of legal majority where they live. We do not knowingly collect personal information from children. If you believe a child has provided personal information, contact us and we will delete it.

10. International data transfers

We and our providers may process data in the United States and other countries. Where we transfer personal data out of the European Economic Area, the United Kingdom, or Switzerland, we rely on appropriate safeguards such as the European Commission’s Standard Contractual Clauses and equivalent mechanisms.

11. Security

We use reasonable technical and organizational measures designed to protect your information, including encryption in transit, encrypted storage of authentication session credentials on the device, encryption at rest for server-held Apple and Google revocation credentials, and access controls on our systems. No method of transmission or storage is completely secure, and we cannot guarantee absolute security.

12. Data breach notification

If a personal data breach occurs that is likely to result in a risk to your rights, we will notify the relevant supervisory authority and, where required, affected users, within the timeframes set by applicable law, including within seventy-two (72) hours where the GDPR applies and without unreasonable delay where US law applies.

13. Changes to this policy

We may update this policy as the app evolves or the law changes. When we make material changes, we will update the date at the top and, where appropriate, provide additional notice in the app. Your continued use after an update means you accept the revised policy.

14. Contact

For privacy questions or requests, email axlyne@proton.me. For general support, email axlyne@proton.me. Omniscient Labs LLC (“we”, “us”, or “our”) is the data controller for the processing described here. Our operations are based in Arizona, United States.

15. Do Not Track and Global Privacy Control

Axlyne is a mobile app and does not use web cookies or cross-site tracking, so browser Do Not Track and Global Privacy Control signals do not apply within the app. We do not track you across other apps or websites for advertising.

16. California Shine the Light

California Civil Code Section 1798.83 lets California residents request information about disclosures of personal information to third parties for their direct marketing purposes. We do not share personal information for third-party direct marketing, so there is nothing to disclose. You may still contact us to confirm.

17. Cookies and tracking technologies

The app itself does not use advertising cookies or third-party tracking technologies. Our providers may use strictly necessary identifiers to deliver their service, such as authenticating an account session or attributing a subscription. We do not use these for advertising.

18. Automated decision-making

A future separately authorized, evidence-bound candidate would enable optional generative AI chat only after the required gates were satisfied. It would summarize a saved record and help prepare questions for a qualified technician. It would not provide AI diagnosis or automated decision-making that produced legal or similarly significant effects about you. Neither that future chat nor the diagnostic screens would decide whether a vehicle was safe to drive or what repair it needed.