Boosthis — Terms of Service & Privacy Policy

Part A — Terms of Service

1. Acceptance and eligibility

• By installing, enabling, configuring, or using Boosthis — including adding it to source code, running its runtimes, calling its APIs, or connecting to its servers — you accept these Terms.
• You may use Boosthis only if you can form a binding contract with us and are at least 16 years old. Boosthis is a developer tool and is not intended for children.
• To purchase a paid subscription you must additionally be of the age of majority where you live, or be acting with the authority of an organization that is.
• If you use Boosthis on behalf of an organization, you represent that you have authority to bind it, and "you" includes that organization.

2. Definitions

• "Boosthis" / "the Service" — the Boosthis software (the runtime kits we publish — for phone apps, browsers, servers and hosted edge functions — and any other runtimes we add), the rule book, the CLI tools, the MCP and HTTP servers, the hosted telemetry API, the developer and admin dashboards, and all related documentation. The kits are listed, with what each one can measure, on our public pricing page; what a kit measures differs by runtime, as described in Part B.
• "Telemetry" — everything your app sends to Boosthis: the always-on issue signatures and fix-resolution signals, and any optional full performance samples you choose to enable (detailed in Part B).
• "Project Key" (called an "project key" in parts of the product and its code) — a credential you create from your dashboard that lets one registered project of yours report to, and read back from, the hosted service. Older accounts may hold a key the Maintainer issued by hand; both work the same way.
• "Account" — the developer account you create to use the hosted web and mobile dashboards. Creating one is open to the public and requires your full name, an email address, and a password.
• "Workspace" — an Account together with any teammates its owner has invited, and the projects, keys, and data they share.
• "Veqtara Tech Company" (the "Company") — Veqtara Tech Company, commercial registration (CR) number 7054832287, registered in the Kingdom of Saudi Arabia and trading as Boosthis. The Company is the Maintainer: the legal entity that operates the Service, that you contract with under these Terms, and that sells and invoices every Paid Plan.
• "Maintainer" — the creator, owner, and operator(s) of Boosthis.
• "Protected Parties" — the Maintainer together with Boosthis's owner, creator, administrator(s), operator(s), contributors, and licensors, and each of their respective affiliates, officers, employees, and agents. Every disclaimer, limitation, release, and indemnity below runs in favour of all Protected Parties.
• "Paid Plan" — an optional paid subscription to the hosted Boosthis service (described in Section 15).
• "Payment Processor" — the third-party payment platform (currently Moyasar) that hosts checkout and processes subscription payments on the Maintainer's behalf.

3. Accounts, Project Keys, and workspaces

• Anyone can create an account. Sign-up is open to the public. You give your full name, an email address, and a password; you must keep those details accurate, keep your password and sign-in codes confidential, and you are responsible for everything done under your Account. One person, one Account — do not share Account credentials. Accounts created before the name became mandatory are asked for it once, the next time the account holder opens the dashboard.
• Project Keys are yours to create and to protect. You mint them from your dashboard (how many you may hold at once depends on your plan). You must not share, resell, sublicense, publish, or transfer a Project Key, and you are responsible for all activity under your Project Keys and install IDs.
• We may rotate, disable, or revoke keys at any time, and are not liable for any consequence of a revoked or expired key.
• Access is still discretionary. Creating an Account does not entitle you to the Service indefinitely: the Maintainer may refuse, limit, suspend, or revoke access at any time — for example for abuse, non-payment, or breach of these Terms — as described in Section 14.
• Teammates see your workspace data. You may invite teammates by email address. Anyone who accepts can see that workspace's projects, their performance data, and its activity log; billing, Project Keys, and AI tokens stay under the workspace owner's control. The number of seats depends on your plan. Invite only people you are willing to share that data with, and remove them when they no longer need access.

4. License to use Boosthis, and restrictions

The Boosthis software is licensed to you under the project LICENSE (Apache License 2.0), which governs your rights to use, copy, and modify the code. These Terms govern your use of the Service (including the hosted telemetry API, the hosted dashboards, and the AI tooling). Where both apply, the Apache License controls your rights in the code and these Terms control your use of the Service; nothing here limits, modifies, or adds conditions to the rights the Apache License grants in the code. Except as permitted by the LICENSE — and in every case when interacting with the Service — you must not:

• use Boosthis or its servers unlawfully or in violation of these Terms;
• probe, scan, overload, rate-abuse, or attempt unauthorized access to the telemetry API, admin dashboard, or any Boosthis infrastructure;
• attempt to bypass, disable, or weaken the PII guard, the privacy chokepoint, or any access control;
• tamper with, remove, disable, or circumvent — or assist or direct anyone or anything (including any AI agent or automated tool) to tamper with, remove, disable, or circumvent — the Service's activation, entitlement, kill-switch, or integrity-verification mechanisms, or misrepresent your install's identity, version, or integrity state to the Service;
• submit false, poisoned, automated, or bulk telemetry intended to corrupt the rule book or analytics;
• remove, obscure, or misrepresent any notice, license, or attribution; or
• use Boosthis to build a competing dataset or service from telemetry you do not own.

5. Acceptable use

You are solely responsible for your own application, source code, data, users, and for what you place into route names, labels, metadata, and exception messages. You must not use Boosthis to process, transmit, or expose unlawful content or to violate any third party's rights.

You must have the right to instrument the application. You represent and warrant that, for every application, service, or site you install Boosthis into, you either own it or are authorised by its owner to install monitoring software in it and to transmit its telemetry to the Maintainer. You must never install Boosthis into an application you do not own or control, and never use a Project Key to collect telemetry on behalf of anyone who has not authorised it.

Prohibited uses. In addition to Section 4, you must not use Boosthis, its API, its dashboards, or its AI tooling:

• for any unlawful purpose, or in furtherance of any criminal activity;
• to monitor, profile, track, locate, or gather information about any person, or about any organisation's application, without the right to do so — including covert surveillance, stalking, or harassment;
• to collect, infer, or transmit personal data, special-category data, payment card data, authentication credentials, or secrets through any Boosthis field, label, name, or message;
• to develop, host, distribute, test, or operate malware, ransomware, credential-stuffing, denial-of-service, scraping, or intrusion tooling, or to support, plan, or conceal an attack on any system;
• to reach, read, or attempt to reach any project, key, install, account, or telemetry that is not yours;
• in breach of applicable export-control or sanctions law (see Section 18); or
• in any way that would place the Maintainer in breach of any law, or of any payment-network, registry, or hosting-provider rule.

Enforcement. Where the Maintainer reasonably believes this Section has been breached, it may — immediately, without notice, and in addition to every right in Section 14 — suspend or terminate your account, revoke or rotate your Project Keys, disable affected installs through the Service's activation and kill-switch mechanisms, and refuse further service. No refund is due for a suspension or termination under this Section. The Maintainer may also preserve and disclose records where required by law, or where it reasonably believes disclosure is necessary to prevent serious harm, and will cooperate with lawful requests from competent authorities.

Reporting misuse. If you believe Boosthis is being used in breach of this Section, email support@boosthis.com with "abuse" in the subject. Include whatever detail you can; reports are reviewed by the Maintainer.

What the Maintainer can and cannot see. Boosthis receives performance and crash telemetry only — never your source code, your files, or your end users' data (see Part B). The Maintainer therefore cannot inspect, supervise, or police what your application does, and nothing here is a representation that it does. Operating your own application lawfully is your responsibility alone; this Section defines what is forbidden on the Service and what the Maintainer will do when it learns of a breach.

6. Boosthis intellectual property

As between you and the Maintainer, the Maintainer owns all right, title, and interest in and to Boosthis — including the software, the rule book, the detectors, the scoring model, the documentation, the name "Boosthis", and all associated logos and trademarks — except for the rights expressly granted to you under the LICENSE. Nothing here transfers any Boosthis intellectual property to you.

7. Ownership and assignment of Telemetry

By installing, enabling, or otherwise using Boosthis with a registered app, you agree that everything your app sends to Boosthis — the issue signatures, the fix-resolution signals, and any optional full performance samples you turn on (together, the "Telemetry") — is assigned to Boosthis: you waive, and irrevocably assign to the Maintainer, all right, title, and interest you may have in the Telemetry and in any rules, thresholds, aggregated statistics, models, or other improvements derived from it, and you will not claim ownership of — or any compensation for — the Telemetry or anything built from it. This applies whether or not you turn on full data mode (enableTelemetry()) — enabling full samples does not give you any ownership claim over what you send.

This expressly includes every issue, error, bug, and fix. When an issue, error, bug, defect, crash, or performance problem is surfaced by the Telemetry your app sends, or is identified, reproduced, diagnosed, derived, or generated by Boosthis — together with every fix, patch, workaround, rule, remediation, signature, insight, or rule-book entry Boosthis creates from or about it — all right, title, and interest in that Telemetry, finding, fix, rule, and rule-book entry belongs to the Maintainer, and you irrevocably waive and will not assert any ownership, authorship, inventorship, royalty, or other claim over them. This is about Boosthis's record and remediation of the problem, not the underlying defect in your own code: as below, the assignment never reaches your source code, diffs, file contents, or application, which remain entirely yours.

This covers only what you send — the data described in Part B (issue & fix signals, plus, in full mode, route labels, durations, and ratings). Boosthis never receives your source code, diffs, file contents, or your application, and this assignment gives the Maintainer no rights over any of them. Your code and your app remain entirely yours. The assignment survives erasure and termination: running forget stops future Telemetry but does not claw back rules already derived and shipped.

8. Feedback

If you send the Maintainer any feedback, ideas, suggestions, or bug reports, you grant a perpetual, irrevocable, worldwide, royalty-free license to use them for any purpose, without obligation or compensation to you.

9. AI-generated suggestions are not approvals

Boosthis surfaces performance rules and AI-assisted fix suggestions through its MCP server, HTTP API, and documentation. These are suggestions, not approvals. You are solely responsible for reviewing, testing, and deciding whether to apply any suggested change before you ship it.

The "Ask Boosthis" assistant. The dashboard assistant answers questions about your own telemetry. It is software, not a person; it is not professional advice of any kind — medical, psychological, legal, or financial; and it is not an emergency or crisis service. If what you type appears to describe self-harm or harm to another person, the assistant replies with crisis-line information instead of an AI answer. That reply is automatic: nothing is monitored, no one is alerted, and no one is watching the box. In an emergency, contact your local emergency number or a crisis line directly.

10. Third-party dependencies and services

Boosthis may rely on third-party software, registries, AI providers, and hosting platforms. Your use of those is subject to their own terms, and the Maintainer is not responsible for them.

11. Disclaimer of warranties

Boosthis is provided "as is" and "as available," with all faults and without warranty of any kind, whether express, implied, or statutory, including without limitation implied warranties of merchantability, fitness for a particular purpose, title, non-infringement, and accuracy. No Protected Party warrants that Boosthis will be uninterrupted, timely, error-free, secure, or free of harmful components, that any defect will be corrected, or that the PII guard will catch every identifier or secret — it is a best-effort defence, not a guarantee. You assume the entire risk as to quality, performance, and results, and use Boosthis entirely at your own risk. Boosthis is not designed, intended, or licensed for use in high-risk activities — including medical or life-support systems, aviation, nuclear facilities, weapons systems, or any other environment where a failure could lead to death, personal injury, or severe physical or environmental damage — and no Protected Party is liable for any use of Boosthis in such activities. This restates and supplements the warranty disclaimer in the LICENSE (Apache License 2.0, Section 7); to the extent of any conflict, the broader disclaimer applies to your use of the Service. Some jurisdictions do not allow some exclusions, so they may not apply to you.

12. Limitation of liability, assumption of risk, and release

Use at your own risk — no liability. You use Boosthis entirely at your own risk. To the maximum extent permitted by law, none of the Protected Parties (defined in Section 2 — including the owner, creator, and administrator of Boosthis, its maintainers and contributors) will have any liability of any kind to you or anyone else for any loss or damage arising from or relating to Boosthis — including any data exposure, leak, loss, corruption, downtime, security incident, or business loss. This clause works together with Sections 11–13. If you do not accept this, do not install or use Boosthis.

No liability. To the fullest extent permitted by law, in no event will any Protected Party (including the owner, creator, and administrator of Boosthis) be liable to you or any third party for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for any loss of profits, revenue, business, data, goodwill, or other intangible losses, or for any data exposure, leak, loss, corruption, downtime, security incident, or regulatory penalty, arising out of or related to Boosthis or these Terms — whether based on warranty, contract, tort (including negligence), strict liability, statute, or any other theory, whether or not advised of the possibility, and even if a remedy fails of its essential purpose.

Liability cap. To the extent any liability cannot be fully excluded, the Protected Parties' total aggregate liability for all claims will not exceed the greater of (a) the amount you actually paid the Maintainer for Boosthis in the prior twelve months and (b) SAR 100. This cap is aggregate across all claims, not per-incident. For any no-charge product the lower cap in Section 16 applies instead.

Assumption of risk & release. You knowingly and voluntarily assume all risk arising from your use of Boosthis and any change you make in reliance on it, and you release and forever discharge the Protected Parties from all claims, known or unknown, arising out of or related to Boosthis, the Telemetry, or any AI-suggested change. This restates and supplements the limitation of liability in the LICENSE (Apache License 2.0, Section 8); to the extent of any conflict, the broader limitation applies to your use of the Service. Some jurisdictions do not allow certain limitations, so some may not apply to you; in that case the Protected Parties' liability is limited to the minimum permitted by law.

13. Indemnification

To the fullest extent permitted by law, you agree to defend, indemnify, and hold harmless the Protected Parties from and against any claims, damages, liabilities, losses, and expenses (including reasonable legal fees) arising out of or related to: (a) your use of Boosthis; (b) your application, source code, data, or users; (c) the data you place into route names, labels, or metadata; (d) your violation of these Terms or any law; or (e) your violation of any third party's rights.

14. Term, suspension, and termination

• These Terms apply for as long as you use Boosthis.
• The Maintainer may suspend or terminate your access (including your Account, your Project Keys, and telemetry participation) at any time, with or without notice, for any reason, without liability.
• Tampering is a material breach. Tampering with, removing, disabling, or circumventing the Service's activation, entitlement, kill-switch, or integrity-verification mechanisms (or assisting or directing anyone or anything to do so) is a material breach of these Terms and results in immediate termination of your access, Project Keys, and telemetry participation, without notice or liability. The Maintainer may also pursue any remedy available at law or in equity for such breach; no remedy is exclusive, and declining to pursue a remedy is not a waiver.
• You may stop at any time: disable optional samples, set BOOSTHIS_DISABLED=1, or run forget (see Part B).
• Non-payment is a freeze, never deletion. If a Paid Plan lapses, your account and data are frozen, not deleted: growth actions pause, but everything you already collected stays viewable, nothing is erased, and everything unlocks the moment payment resumes (see Section 15).
• Revocation or suspension starts a deletion countdown. If your access is revoked or suspended, a 60-day countdown to deletion of the associated stored data begins. Restoring your access before it ends cancels the countdown. Running forget deletes immediately at any time. Learning signals survive deletion only in permanently de-identified form, as described in Section 7 and Part B.
• Sections that by their nature should survive — including 6, 7, 8, 11, 12, 13, 15 (for fees already owed), 16, 17, 20, 22, and 26 — survive termination.

15. Subscriptions, billing, and payment

Boosthis offers optional Paid Plans — subscriptions billed either monthly or yearly, whichever you choose at checkout, that unlock higher limits and additional features on the hosted service. The plans, prices, the billing period, and what each includes are shown on the billing page at the time of purchase.

• Payment is handled by the Payment Processor. Checkout happens on the Payment Processor's own hosted pages, under its own terms and privacy policy. Your card details go to the Payment Processor and never touch Boosthis's servers. Boosthis stores which plan you are on, a reference to your subscription, and — so renewals work and you can recognize the card — your card's brand, its last four digits, and a reusable payment token issued by the Payment Processor (never the card number itself).
• Changing plans. An upgrade takes effect immediately: you pay only the prorated difference for the remainder of the current period, and your renewal date does not move. A downgrade takes effect at your next renewal, so you keep what you paid for until then. If a quoted upgrade price is no longer valid when payment completes, the payment is refunded rather than applied.
• Failed or declined renewals. If a renewal payment is declined we email the Account address and your plan lapses into the frozen state described below — we do not delete anything, and paying resumes full access.
• Refunds, when issued, are returned through the Payment Processor to the original payment method.
• Plans renew automatically at the end of each billing period — every month on a monthly plan, every year on a yearly one — until you cancel. You can cancel at any time from the billing page or with the Payment Processor; cancellation takes effect at the end of the current billing period, and you keep the paid features until then.
• Fees are paid in advance and are non-refundable, except where a refund is required by applicable law or granted by the Maintainer at its discretion.
• Taxes. All Fees are stated and charged in Saudi Riyal (SAR). The price displayed at purchase is the total amount charged, and it includes VAT and any similar taxes where they apply under the laws of the Kingdom of Saudi Arabia. If the Maintainer is or becomes VAT-registered with the Zakat, Tax and Customs Authority (ZATCA), VAT will be charged and invoiced in accordance with ZATCA regulations at the then-current rate. If you purchase from outside Saudi Arabia, you are responsible for any taxes, levies, or duties imposed by your own jurisdiction.
• Price changes. The Maintainer may change plan prices or features; changes take effect at your next renewal, and any change to what you pay is emailed to you at least 14 days before the first renewal charged at the new price — a renewal falling inside those 14 days is charged at the old price. Continued renewal after a change means you accept it.
• Non-payment never deletes your data. A lapsed subscription only pauses growth actions (such as adding new projects or new connections); everything already collected stays viewable, and full access returns instantly on payment (see Section 14).
• A Payment Processor outage never downgrades you. If the Payment Processor cannot be reached, your last known plan state remains in effect.
• Complimentary access. The Maintainer may grant free or complimentary access at its discretion; such access is a no-charge product under Section 16 and may be modified or withdrawn at any time.

16. Free, beta, and no-charge products

Parts of Boosthis may be provided at no charge — including free features, trials, beta or pre-release versions (such as TestFlight builds of the mobile app), and complimentary or maintainer-granted access (together, "No-Charge Products").

• No-Charge Products are provided "AS IS", with no warranty, no support commitment, and no availability commitment. They may be changed, limited, suspended, or discontinued at any time, and may never become generally available.
• Beta and pre-release versions are by definition unfinished and may contain defects; do not rely on them for production-critical decisions.
• NOTWITHSTANDING SECTION 12, THE PROTECTED PARTIES' TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATED TO ANY NO-CHARGE PRODUCT WILL NOT EXCEED SAR 50.

17. Confidentiality, publicity, and benchmarks

• Parts of Boosthis are not public. Non-public information you receive through it — including the contents of the rule book and fix corpus, non-public documentation, Project Keys and other credentials, non-public dashboards, roadmaps, and pricing not publicly listed — is Confidential Information of the Maintainer.
• You will use Confidential Information only to use Boosthis as permitted by these Terms, and will not disclose or publish it.
• You will not publicly disclose benchmarks or comparative analyses of Boosthis, and will not publicly announce or advertise your use of Boosthis (in marketing, press, talks, or public repositories), without the Maintainer's prior written consent.
• These obligations do not apply to information that becomes public through no fault of yours, or that you are required to disclose by law (with prior notice to the Maintainer where lawful). This Section survives termination.

18. Export controls and sanctions

You represent that you are not located in, or ordinarily resident in, any country or territory subject to comprehensive sanctions or embargoes, and that you are not on any government sanctions or denied-party list. You agree to comply with all applicable export-control and sanctions laws in your use of Boosthis.

19. Changes to Boosthis and to these Terms

The Maintainer may modify, suspend, or discontinue any part of Boosthis at any time without liability, and may update these Terms; the "Last updated" date will change and material changes will be noted in the release. Continued use after a change means you accept the updated Terms. A new consent is requested for any new use of telemetry beyond rule-book improvement.

20. Governing law and dispute resolution

• These Terms are governed by the laws of the Kingdom of Saudi Arabia, without regard to conflict-of-laws rules.
• Informal resolution first. Before filing any claim, you agree to contact the Maintainer and attempt in good faith to resolve the dispute informally for at least 30 days.
• Binding arbitration. Any dispute, claim, or controversy arising out of or relating to Boosthis or these Terms that is not resolved informally will be finally settled by binding arbitration administered by the Saudi Center for Commercial Arbitration (SCCA) under its Arbitration Rules, before a single arbitrator, seated in Riyadh, Kingdom of Saudi Arabia, conducted in English unless the parties agree otherwise. The award is final and binding, and judgment on it may be entered in any court of competent jurisdiction.
• Equitable relief. Nothing in these Terms prevents the Maintainer from seeking injunctive or other equitable relief in any court of competent jurisdiction to protect its intellectual property or confidential information.
• Attorneys' fees. In any action or proceeding to enforce these Terms, the prevailing party will be entitled to recover its reasonable attorneys' fees and costs, in addition to any other relief awarded.
• Time limit on claims. To the fullest extent permitted by law, any claim arising out of or related to Boosthis or these Terms must be filed within twelve (12) months after the claim accrued; otherwise it is permanently barred.

21. Severability · 22. No waiver · 23. Assignment · 24. Force majeure · 25. Entire agreement · 26. Notices

• Severability. If any provision is unenforceable, it will be limited or removed to the minimum extent necessary and the rest remains in force.
• No waiver. The Maintainer's failure to enforce any provision is not a waiver of its right to do so later.
• Assignment. You may not assign these Terms, your Account, or your Project Keys without the Maintainer's written consent. The Maintainer may assign freely, including in a merger, acquisition, or sale of assets.
• Force majeure. The Maintainer is not liable for delay or failure caused by events beyond its reasonable control.
• Entire agreement. These Terms (with the LICENSE and Part B) are the entire agreement regarding Boosthis and supersede any prior understanding.
• Notices. Notices to the Maintainer must be given in writing through the contact channel in Part B (support@boosthis.com) and are deemed given when received. The Maintainer may give you notice by email to your account address, in-product messages or dashboard banners, or release notes; such notice is deemed given when sent or posted.

Part B — Privacy Policy

Boosthis is a developer toolkit. It runs inside your own app on your own machine. This part explains exactly what a registered app reports back to this server, what it never reports, and how to stop it. Separately from the toolkit, anyone can create a developer account (name, email, and password) to use the hosted web and mobile dashboards and manage billing — what we store for an account is described under "Account data" below, and it is never merged with telemetry.

Use at your own risk — no liability for data exposure

Boosthis is provided "as is," with no warranty of any kind, and you use it entirely at your own risk (see Part A, Sections 11–12). Boosthis is a library that runs inside your application's own process — you remain solely responsible for the data your app handles, for what you place into route names and metadata, and for reviewing any AI-suggested change before you ship it. The PII guard is a best-effort defence against common identifier and secret field names, not a guarantee.

Two kinds of data — please read

• Issue & fix signals — always on for registered apps. Once your app is registered Boosthis automatically reports tiny, anonymous, privacy-safe signatures describing that a class of performance issue recurred, and that one later improved. It is not a per-app on/off setting and cannot be turned off from inside the app — it stops only if you erase your data (forget) or set the kill-switch BOOSTHIS_DISABLED=1.
• Full performance details — optional, off unless you turn it on. You may switch on fuller per-route samples (route label, duration, rating). This is the only part controlled by enableTelemetry() / disableTelemetry(). Turning telemetry "off" does not stop the always-on issue & fix signals.

What we use your data for

We use opted-in telemetry for one purpose only — to improve the Boosthis rule book (new rules, refined thresholds, recurring patterns). We do not sell it, share it with advertisers or data brokers, use it for advertising/profiling, train general-purpose AI/LLMs on it, link it to your identity, or combine it with other sources. New uses require a new consent in a new major version.

Ownership of what you send

Everything you send to Boosthis (the "Telemetry") is assigned to Boosthis — you waive any ownership claim over the issue & fix signals and the optional full samples, and over any rules or improvements derived from them, even if you turn on full data mode. This covers only what you send, never your source code or application. The full clause is Part A, Section 7.

What an issue / fix signal contains

• Anonymous install ID — a UUIDv4 generated on your machine. Not linked to your IP, email, account, hostname, or anything else.
• Issue signature — <detector-kind>:<severity-bucket>:<count-bucket>, e.g. ghost-mount:med:<10. The screen / route name is deliberately dropped.
• Fix signal — the same rule kind plus a before→after rating bucket (good / needs-work / poor) when an issue later improves. Never the fix itself: no source code, diffs, file paths, screen names, or values.
• Package version + runtime — e.g. boosthis 0.2.0 (py).
• Anonymous daily reach tag (React Native) — a small random value your device mints fresh each calendar day, never derived from your device, user, account, or install ID. The server folds it into a coarse rolling estimate of roughly how many distinct devices hit the same issue this week ("≈1", "≈2–9", "≈10+") and never stores the tag itself. Because it rotates daily it cannot track a device across days, and erasing your data (forget) also deletes the tag on your device.

What the optional full-details mode adds

• Route label — the code-defined name of the function or route you instrumented (e.g. /api/users, get_orders). The PII guard refuses to transmit it if it contains an email, IP, JWT, phone number, or other identifier.
• Duration in milliseconds and rating (good / needs-work / poor).
• Rule ID (optional) — if you attached a Boosthis rule to the sample.

The page map described below is not one of these fields: it has a switch of its own and travels with the health-meter snapshot, on either of that snapshot's two switches.

The page map (web and React Native)

Boosthis's server can already draw the map of an app's server side, because it can see the calls one part makes to another. It cannot see the front: a browser page or a phone screen moving to another one makes no request, so nothing tells the server that your checkout screen is reached from the basket and never from search. The page map is the front half of that picture, and the browser and React Native kits are the only ones that can draw it.

It is drawn progressively, from your app's own traffic — it is whatever paths people have actually walked, not a route table read out of your config — and it is a picture of how your app is navigated now, not a history: each upload replaces what that copy of your app previously said.

What travels: the route labels of the screens your app moves between, and which of them leads to which — the same code-defined labels as the route label above, in pairs, with a count of how often each path was taken. They go through the same PII guard, so a label carrying an email, IP, token or other identifier is refused exactly as a sample's would be.

What never travels: the name or caption of any control, and the gesture that moved you. Not "the Pay now button", not "swiped", not "tapped at these coordinates". This is not a setting you could turn the wrong way — the kits have no wire shape that can carry those things, so they cannot be swept along by accident. Nothing about who navigated, when they did it, or what they typed is collected either.

It has a switch of its own, and it rides the health-meter snapshot. Nothing is drawn or sent unless your own code asks for it (sendPageMap), and nothing we send back can turn that on. With it on, the map travels with the snapshot described below and on that snapshot's two switches: it is sent only when full details are on, or when you explicitly switch on meter sharing so a connected AI can read the live picture. In issues-only mode with neither of those on, no map leaves the device. disableTelemetry() / boosthis.disable_telemetry(), forget and BOOSTHIS_DISABLED=1 each stop it. A path that stops being reported is deleted after 45 days, and forget deletes your map immediately along with everything else that project sent.

Health-meter numbers (the dashboard meter page)

Boosthis scores your app on a set of named health meters — the tiles you see on the dashboard (the boot ladder, Speed, Smoothness, Scroll, Stability, Render, Frustration and Idle, plus the runtime-specific meters such as event-loop lag, garbage-collection pressure, memory growth, worker health and startup cost). The whole meter page is captured as one small snapshot so you — and an AI you choose to connect — can read your own numbers back. It rides the same optional full-details channel as the samples above: the snapshot is uploaded only when full details are on, or when you explicitly switch on meter sharing so a connected AI can read the live picture. disableTelemetry() / boosthis.disable_telemetry(), forget, and BOOSTHIS_DISABLED=1 all stop it.

Every meter reports the same three things and nothing else:

• A score (0–100) and a rating bucket — good, needs-work, or poor.
• A handful of plain numbers — counts, timings, rates, percentages and sizes. For example: milliseconds spent loading modules before startup finished and how many modules were loaded, kilobytes of memory growth per request, worker restarts per hour, subprocess spawns per minute, how many errors were logged in the window, queue and lock waits in milliseconds, garbage-collection pauses, pending task counts, thread and worker counts, hours of heap headroom left, megabytes read from and written to storage, major page-fault and context-switch counts, or how many open descriptors are sockets versus files.
• Nothing else. No message text, no log lines, no file, module, thread, worker or command names, no source code, no values from your app, and nothing about your users.

The meter set grows over time, and the boundary does not. New meters ship regularly and they differ per runtime (a Python service reports things a browser cannot, and the other way round). Every meter — the ones shipped today and the ones added later — stays inside the same limit: a score, a rating bucket, and numeric counts and timings. That limit is enforced, not just promised. The server keeps a fixed allowlist of numeric meter fields, silently drops any field that is not on it, and rejects any allowlisted field whose value is not a plain number — so no prose can ride in a slot that should hold a measurement. Even the one-line caption a kit computes for its own on-device display is dropped at the door and rebuilt on our side from the numbers. A genuinely new category of data would require a change to this document, not just a new meter.

Two promises spelled out, because these meters count things that sound sensitive:

• A logged-error meter counts errors; it never carries the log. We receive how many errors your app logged and survived during the window and the rate per hour — never the message, the log line, the logger name, the level, the stack, or any value.
• A subprocess meter counts spawns; it never carries the command. We receive how many subprocesses were spawned per minute and the total for the window — never the command line, its arguments, its path, its environment, or its output. In the same way, thread, worker, handle, timer, module and descriptor meters report only how many, never their names — a descriptor meter says how many open descriptors are sockets, pipes or files, never what any of them points at.

The whole route list (the app map, including pages nobody visited)

Alongside the meter snapshot, and on exactly the same two switches, some kits send the list of routes your app has — not only the ones traffic reached. The kit asks your own running framework for its route table (Express, Fastify, Koa and Hapi; FastAPI, Starlette, Flask and Django; Vue Router or React Router if you hand the kit your router; React Navigation on React Native if you hand the kit your navigator’s screen configuration). It is a question put to a running framework through the framework’s own interface. Boosthis never reads your source code, never opens a file of yours, and never crawls or clicks through your app to discover pages.

Be aware of what this adds, because it is the one thing here that travels before any traffic does. Until now, a route label only reached us because a real request went to it. A route list includes paths your traffic would never have revealed — an admin page, an internal webhook, a feature not launched yet, a route left behind. If the existence of a path is sensitive to you, this is the setting to turn off.

• What each entry is. A code-defined route template and nothing else — for example GET /orders/:id, /admin/users/<int:user_id>, or a screen name like Checkout. Parameters arrive as the template your framework holds, so a real order number or user id is never in it. Each entry also records whether it came from the framework, from a list you declared by hand, or both.
• What each entry is not. No timings, no counts, no scores and no ratings ride on a route the kit has not measured — an unvisited route carries a name and nothing else. We never send query strings, handler names, file paths, source, or anything a request carried.
• The same guard, and a stricter disposal. Every label goes through the same PII guard that governs route labels on samples. A label that fails it is dropped entirely rather than redacted, because a redacted route would otherwise draw on your map as a page of your app.
• It is capped, and says so. At most 200 routes travel; the list states how many the kit found, so a larger app reads as “at least this many” rather than as a complete picture.
• How to turn it off. BOOSTHIS_ROUTE_LIST=0 (Node and Python), or setRouteListEnabled(false) (browser and React Native). With it off, the kit says so rather than going quiet, so your map can tell “switched off” from “this kit cannot ask”. disableTelemetry() / boosthis.disable_telemetry(), forget, and BOOSTHIS_DISABLED=1 all stop it like everything else.
• Where it cannot be done at all. Only the kits named above can ask. Every other runtime’s map shows the pages traffic reached and says so on the page, rather than implying your app has no others.
• A quiet route is never called broken. A route the framework lists and traffic never reached is shown as not seen — never “dead”, “unused” or “broken”. We cannot know why it is quiet, and we do not guess.

What the phone platform allows (phone apps only)

The four phone kits — React Native, Flutter, Swift/iOS and Android/Kotlin — report, alongside the meter snapshot and on exactly the same two switches, a short closed list of observations about what the operating system let the app do. Nothing here is about your app, your handset, or the person holding it.

Why it exists: a phone app is held to more rules than any server — background execution windows, doze and app-standby, per-app memory ceilings the system enforces by killing you, timers that quietly stop — those rules changed with almost every OS release, and the published documentation is frequently wrong. So each kit records what actually happened on the platform it was running on, we pool it across installs, and the rules Boosthis gives you for phones are then written from what the platform really does rather than from what it says about itself.

Exactly this travels, and nothing else:

• The platform's name and one version number — the operating system word (ios, ipados or android) and either the iOS major version or the Android API level. The version is here for one reason: a rule that changed between two OS releases, filed under a single name, is a wrong answer rather than a vague one. Both are read from the operating system's own version report; nothing is inferred about the handset.
• The manufacturer — Android only, and only from a short fixed list — Samsung, Xiaomi, Google, Sony and a handful of others whose own battery management genuinely changes whether a background job runs at all. A maker not on the list is dropped rather than sent, because a rare name is closer to naming one handset than to naming a platform. Never the model, the device name, a device identifier, the OS build string, the carrier, the locale, the screen, the battery, or anything else about the phone.
• Up to seven yes/no observations, each of something the kit watched happen — whether work already in flight finished while the app was in the background, whether a timer already scheduled fired while it was away, whether the system warned the app before it ran short of memory, whether the app could read its own memory ceiling and its own CPU clock, and, on Apple platforms, whether the system will say how much background time is left and whether that number counts down. Each arrives as a plain 1 or 0, and a fact this kit could not observe is left out of the block entirely rather than reported as a 0 — a limit we never watched being reached is not a limit we may claim. No measurement is taken to answer these: each one is a by-product of work the kit was doing anyway.

These are facts about a platform, not about a device. They are pooled per platform band: what survives is “on Android API 34, this many installs saw a background job run in the background and this many did not”. No line is shown until at least three separate installs have reported it, each install counts once per fact however many times it uploads, and nothing in the pooled record can be traced to a particular phone. Your own install row additionally remembers which band and maker it reported — that, and nothing more about the device — so your dashboard can tell you which platform your project runs on; forget and account closure delete it with the rest of the row.

What a crash report contains

Crash reports are part of the always-on signals for a registered app. When your app hits an uncaught error, an unhandled promise rejection, or a render crash, Boosthis records only the crash's code — the minimum needed to identify and fix it. It is the crash's code, not your users' data, your values, your message text, or your source. Like every other finding, a crash and the fix Boosthis derives from it become a Boosthis rule (see Part A, Section 7).

• Error type — e.g. TypeError (always on). Never the message text.
• Redacted code location — the top stack frame reduced to a function name + file basename + line number. Never an absolute path, URL, query string, argument, or value.
• Hashed signature + occurrence count — the signature is derived only from those code-defined tokens, never from the error message; the occurrence count is just how many times that same crash recurred. The server keeps one row per (install, signature); repeats add to a running total.
• Duplicate suppression only — current kits also send a short-lived, non-readable batch fingerprint so a retry after a lost response cannot add the same occurrences twice. It is operational duplicate-suppression metadata, not customer crash history: it is excluded from customer exports, capped at 30 days and 1,024 receipts per install, and erased with the install.
• Optional detailed crash mode (opt-in, per app) — adds the first line of the message only if it passes the PII guard (otherwise the whole line is dropped, never partially redacted), plus sanitized frames (function + file basename + line/column). Still no source code, no raw stack, no values; the PII guard runs on every field first.
• You can read these back, read-only — the "potential crashes" feed. An AI agent you connect (the dev-only "Connect your AI" card, or "Connect AI" in the web dashboard) can read your app's own recorded crash codes back, newest first, joined with your app's stability (app-not-responding) signal, so it can flag what is most likely to crash and what to harden first. This reads the same crash data already collected — no new categories — scoped to your own install, read-only, same PII guard on every read.
• What a tool reply can contain — the exact identifier categories. A reply served to a connected AI is limited to: your anonymous install ID (the same UUID described above — the connection-status tool lists it per app so you can tell your installs apart and match the “Connect your AI” card); trace and span correlation IDs (a random 32-character hex value minted inside your app purely to stitch one user action's spans into a waterfall — never derived from your device, user, account, or install ID); code-defined route/screen labels; durations, ratings, and scores; crash signatures (error type plus a redacted code location); coarse timestamps (when a sample or crash was recorded, and when an app last checked in); connection-status facts (each install's coarse connection status, when it was registered, whether it has ever checked in, whether a measurement has ever arrived from it, when the most recent one arrived and a coarse band of how many have arrived, and a yes/no of whether server-side credentials are on file — never any credential value, and never a measurement value itself); the project name and short code the reply is about (the name you gave that project on your dashboard, plus the first characters of its project key's fingerprint, so a connected AI holding two connections can always say which project a set of numbers belongs to); the app name and runtime label of the install being read (the name your app reported when it registered, so a connected AI can tell one measured place of a project from another instead of judging the whole project on half its numbers); rule IDs and fix guidance from the rule book; and — inside the integration-kit reply only — an echo of the same project key that connection itself presented (so the kit can self-register; never anyone else's key or any other credential). Tool replies never include account data, emails, IP addresses, internal database row IDs, or any other install's data.

Learning from experience — new bugs, issues & fixes

When Boosthis runs into a slow or buggy pattern it doesn't yet have a rule for, it may send a small, privacy-safe note about the kind of problem — the runtime, a coarse category, a severity bucket, a timing bucket, a hashed signature, and a recurrence count. Exactly like an issue signature, this is buckets and a hash, never a screen name, a value, your users' data, or your source. It is part of the always-on signals for a registered app.

• If you've connected your own AI, that AI may also attach a suggested rule — a short title, when it applies, and a suggested fix. Every part of a suggestion passes the same PII / secret / URL guard before it leaves your device, and it is treated as feedback under Part A, Section 8.
• Nothing a consumer sends ever becomes a live rule automatically. A suggestion only lands in the maintainer's private review queue; a human decides whether to hand-write it into the rule book. See Part A, Sections 7–9.

Account data (the optional developer account)

If you create a developer account to use the hosted web or mobile dashboard, we store — separately from telemetry, and only to operate your account:

• Your full name, your email address, and a password hash. The name and email are required to create an account: the name identifies the account holder and becomes the “Billed to” name on receipts, and the email is how you sign in and how we reach you. An older account without a name on file is asked for one on the dashboard; nothing else about the account changes, and the name is never shown to the projects you monitor. The password itself is never stored, only a secure one-way hash. Sign-in uses short-lived, single-use one-time codes (emailed, or from an authenticator app if you enroll one, plus one-time recovery codes if you generate them), also stored only as hashes.
• The Maintainer can see your account. In the admin dashboard the Maintainer sees the account holder’s name and email address, along with the plan, the number of projects, and the account’s status (active, frozen, suspended). This is how accounts are supported, billing questions are answered, and abuse is spotted. It is never sold, shared with advertisers, or joined to telemetry.
• Teammates and the workspace activity log. If you invite a teammate, we store the email address you invited and, once they join, the link between their account and your workspace. Actions taken in a workspace (who invited or removed whom, who created or revoked a key, who changed the plan) are recorded in an activity log visible to the workspace owner and admins, kept for up to a year. No IP addresses are stored in it.
• AI connection credentials (OAuth sign-in and “Connect AI” tokens). If you connect an AI assistant through the OAuth sign-in flow, or mint an account AI token from your dashboard, we store that authorization so the assistant can act with its own revocable, read-only credential instead of your password or project key. These credentials are stored only in protected form (hashed, or encrypted where the sign-in flow requires it) — never as plain text — and they inherit the status of the key they were authorized with: revoking that project key immediately ends that assistant's access (dashboard-minted AI tokens can additionally be revoked individually from your dashboard). They grant no more than the read-only tool access described in the sections above.
• AI read events (for the “AI impact” view). When a connected AI assistant actually reads a project's data with one of the credentials above, we record the time of that read (collapsed so bursts count once per hour) together with a snapshot of the project's open crash-group counters at that moment. This exists solely to power the dashboard's honest before/after “AI impact” view; it contains only identifiers and counters we already store — no new content, and never anything about what the AI itself said or did. These events are deleted with the project's other operational data on erasure and pruned after a year.
• Which door you arrived through. One coarse word recorded when the account is created — a search engine, a social site, another site, one of our own pages, the phone app, or nothing we could read — worked out on our own server from the same referring host name described under “Counting visits to our website”. It is a single word from a fixed list, so we can tell whether a place we posted about Boosthis brought anyone. There is no link, no query string, no address and no journey behind it: nothing follows you from page to page, and this one word is all that is kept.
• Session records and essential cookies. The web dashboard sets only essential sign-in cookies (your session, and a short-lived cookie during the one-time-code step). There are no advertising, analytics, or cross-site tracking cookies. The dashboard uses a small amount of your browser's own storage for convenience — for example, remembering that you dismissed the “update available” banner — not for tracking.
• Account emails. We send account emails — a welcome note when you sign up, sign-in codes, password resets, receipts and renewal reminders, plain-language notices when a payment is declined or your access or plan changes, performance-alert emails if you turn alerts on, an optional weekly summary of your projects, and occasional low-frequency update notes about the toolkit — through Resend, our email delivery provider, which processes your email address for delivery only (see “The companies that can see your data” below). If you configure an alert webhook, the alerts you asked for are also POSTed to the URL you supply; where that URL goes, and what the receiving service does with it, is your responsibility.
• Billing status. If you subscribe to a Paid Plan, we store which plan you are on, a reference to your subscription with the Payment Processor, and — so renewals work and you can recognize the card — your card's brand, its last four digits, and a reusable payment token issued by the Payment Processor (never the card number itself). Your card details never touch Boosthis's servers — checkout happens on the Payment Processor's own hosted pages under its own privacy policy (see Part A, Section 15).
• A security log. Sensitive account and maintainer actions are recorded in an append-only security log (including the acting IP address) so we can investigate abuse. It is a security record, not telemetry, and is never shown to other users.
• Support messages. If you write to support — by email or from the dashboard — we keep your message (your address, the subject, and the text) so we can reply and keep a record of the request. Support mail is never joined to telemetry.
• Questions you ask the assistant. Questions put to “Ask Boosthis” and the answers returned are stored against your account so the conversation and your usage allowance work; see the next section for what is sent to the AI provider.
• Standing promises you set on a project. A project can hold a small set of short, plain-language standing promises — things you want kept as the project changes, such as “the list screen stays under a second”. You write them on your dashboard, a connected AI assistant can write one down on your behalf, or you accept one Boosthis offers from your own numbers. We store the sentence itself, who wrote it, whether you have confirmed it, and the single measurement and threshold it maps to when there is one — and where there is none, it is labelled as remembered only, never as something we check. Promises are held against the project key, so every runtime of that project and every teammate on the account sees one shared set, and they are handed to any AI assistant that connects with that key. They are screened going in and coming out: a promise containing a credential, a token or someone's personal data is refused whole and nothing is stored. Chat transcripts, source files and documents are never stored this way — each promise is capped at a couple of sentences and a project holds only a handful. You can correct or delete any promise at any time; promises appear in your data export, are deleted with the project or the account, and are never deleted for non-payment.

Account data is never merged with telemetry: telemetry is keyed to anonymous install IDs, account data to your email, and we do not join them for profiling, advertising, or any other purpose. You can delete your account yourself, without asking anyone: Dashboard → Delete account, or the same option in the Boosthis phone app. You are shown exactly what is deleted and what we must keep before you confirm, and you can download everything we hold about you first (Dashboard → Your data → Download). forget erases your telemetry at any time, independently of your account.

The companies that can see your data

Boosthis is operated by Veqtara Tech Company. A small number of outside companies are involved in running it, and each one is named here. This is the whole list: no other company receives your account data or your telemetry.

• Moyasar — payments. Hosts checkout and processes subscription charges; this is the Payment Processor defined in Part A, Section 2 and described in Part A, Section 15. What reaches it: your card details, entered on Moyasar's own pages and never on Boosthis's servers; the amount and currency of each charge; the billing name and email on the payment; and the reusable payment token that makes a renewal work. Where it runs: the Kingdom of Saudi Arabia. If you pay with Apple Pay, the payment sheet is additionally between your own device, Apple and Moyasar — Boosthis's servers only ask Moyasar to validate the session.
• Resend — email delivery. Sends the account emails listed under “Account data” above. What reaches it: your email address, the subject, and the body of that message. No telemetry, and nothing else about your account, goes with it. Where it runs: the United States.
• OpenAI — AI processing. Generates the answers from “Ask Boosthis” and helps draft candidate rules on our side, reached through Replit's AI Integrations gateway. What reaches it: from your account, only the two things described under “The 'Ask Boosthis' assistant” below — your screened question and a privacy-safe digest of numbers — and, for rule drafting, the aggregated privacy-safe signals described there. It also receives the text of our own rule book, which is ours and not yours: rule titles, the conditions that decide when a rule applies and the detector patterns behind them, and — on the maintainer-side drafting and review calls that cannot do their work without it — the prescriptive fix text itself. OpenAI publishes that what its API receives is not used to train its models — the provider's published position, not a setting we can show you for the account we reach it on; see “What the AI provider may keep, and what we cannot show”. Where it runs: OpenAI is a United States company, and its published residency options do not include the Kingdom — so what reaches it leaves. Which country actually processes it is not confirmed, because we reach the model through Replit's gateway rather than an OpenAI account of our own; see “Where Boosthis runs, and whether your data crosses a border” below.
• Replit — hosting and the database. Runs the Boosthis servers and the managed PostgreSQL database, and operates the AI gateway above. What reaches it: everything this document describes as stored — account data, telemetry, and the operational database as a whole. Where it runs: on Google Cloud infrastructure in the United States.
• Google Cloud — backup storage. Holds the routine backups of the operational database described under “Retention” below, in a private bucket provided through Replit's App Storage. What reaches it: a copy of the operational database. Where it runs: the United States.

Two things are deliberately not on this list, because they are yours rather than ours: an alert webhook you configure (the alerts go to whatever URL you supply, and what the receiving service does with them is your responsibility), and an AI assistant you connect through “Connect AI” or the OAuth sign-in flow (that assistant is your tool, reading your data with a credential you can revoke at any time; whoever operates it is a company you chose, not one we engaged).

We never sell your data. Personal information — your name, your email address, your account, your billing details — is never sold, rented, traded, or shared for anyone else's marketing or advertising, and neither is telemetry. No money and no data change hands for advertising purposes. Each company above may use what it receives only to do the job named beside it.

Notice before this list changes. Before another company starts receiving account data or telemetry, it is named here first — with the revision date at the top of this document moved — at least 14 days before it begins, unless a change has to be made sooner to keep the service running or secure, in which case it is named here as soon as it takes effect. This document is the notice: the same list stays in the same place, so a change is visible by comparing it.

Where Boosthis runs, and whether your data crosses a border

Two questions, two answers. They are easy to blur, and the difference is exactly what matters, so both are stated separately here — and both are generated from the list above rather than written by hand, so they cannot drift from it, from each other, or from the same two sentences in the controlling TERMS.md.

• Where the service runs: the Boosthis servers and the database behind them run in the United States.
• Whether your data crosses a border: some of it does. Moyasar holds what reaches it in the Kingdom of Saudi Arabia; Resend, Replit and Google Cloud hold what reaches them in the United States; what reaches OpenAI leaves the Kingdom of Saudi Arabia too, but which country processes it is not confirmed.

These are two answers to two questions, and neither one implies the other. That the service runs in the United States does not mean nothing leaves it, and that something leaves it does not mean the service runs anywhere else.

Every company outside the Kingdom is on that list because a part of the service cannot be provided without it, and each receives only what is named beside it. The basis for that processing is set out under “Your rights over your data” below. If you would rather nothing crossed a border at all, a general install of the toolkit sends nothing anywhere.

The "Ask Boosthis" assistant (AI processing)

The dashboard includes an optional assistant you can ask plain-English questions about your app's performance. When you use it, two things — and only those two things — are processed by OpenAI, reached through Replit's AI Integrations gateway (see “The companies that can see your data” above), to generate the answer:

• Your typed question. It is checked first: a question containing personal data or a link is rejected rather than sent.
• A privacy-safe digest of your app's already-uploaded performance snapshot — numbers, ratings, and code-defined labels only. Free-form prose and anything identifier-shaped is dropped or blocked before it leaves the server, and the answer that comes back is screened again before you see it.

Nothing new is collected for the assistant, and it runs only when you ask a question. OpenAI's published position for its API is that what it receives is not used to train its models — that is the provider's published position, and what we can and cannot show you about it for this account is set out under “What the AI provider may keep, and what we cannot show” below.

Rule drafting on our side. Separately from the assistant, the Maintainer uses the same third-party AI provider on a schedule to help draft candidate rules from the aggregated, privacy-safe signals described above — rule kinds, severity and timing buckets, redacted code locations, and occurrence counts; never route labels from full samples, never your question, and never anything identifier-shaped. Drafts only ever land in the maintainer's private review queue, and a human decides what ships (see "How candidate rules become real rules"). This is rule-book improvement — the single purpose described above. The provider's published position on training covers this traffic too, subject to the same limit on what we can show you.

What the AI provider may keep, and what we cannot show. The sentence above rests on OpenAI's own published position for its API, which says that what it receives is not used to train its models. We read that position on 14 September 2026. It is the provider's default for API traffic, and switching it off is a choice made on an account — and we reach the model on Replit's gateway account, not one of our own. So we can show you the provider's published default; we cannot show you that this particular account runs on it.

How long a prompt survives is not established, and we record that as unknown rather than assume it. OpenAI's published default deletes an API input after at most 30 days of abuse monitoring, with immediate deletion available only by prior arrangement, which we have not sought. Whether the gateway operator's account runs on that default is not published. The gateway operator does publish a position of its own, which we read on 15 September 2026, and it settles nothing here: it states that training is disabled for paid model providers, and that zero-retention endpoints are enforced for Enterprise accounts only. Neither branch names the plan this path runs on, and the gateway publishes nothing about what it logs or for how long. A prompt may therefore survive in two places on this path, and we are not in a position to tell you for how long at either. Settling it needs an answer from the gateway operator; until then this paragraph says so.

Does your own contribution reach a third-party model? What a customer sends — a question, a measurement — is covered above. The rule book's own text is ours rather than yours, and it does reach the provider when we draft and review rules: the prescriptive fix wording for a rule under review, and for the language passes, the rule being translated. Every call that carries it is listed in our code, with the reason the answer needs it, and the sending of it is bounded — a drafting call carries one rule, or two fixed examples, never a sweep of the book.

Security reports from our own website

Pages on the Boosthis website carry a report-only browser security policy. If a page tries to load something that policy does not list — most often a browser extension rewriting the page, occasionally the signature of injected code — your browser sends us a short report. Nothing is ever blocked on your side; the policy only reports.

From that report we keep three coarse things: which kind of content was involved (for example a script or an image), the host name only of where it came from (never a full link, path, or query string), and a stripped-down label for the page it happened on (identifier-shaped parts replaced). No IP address, no account, no session, no device, and nothing else about you is stored, and identical reports are counted rather than stored twice. These reports are about the security of our own website, are visible only to the Maintainer, and are deleted after 90 days.

Counting visits to our website

We count visits to the public Boosthis website — the pages anyone can open without signing in — so we can tell how many people come and what they read. It is a counter, not tracking: no cookie is set on any visitor, no script of ours runs in your browser on those pages, and nothing kept can be tied back to you.

For each public page we answer we add one to a small set of counts, kept per hour: which page it was, which of our public addresses it was opened on, the host name only of the site that linked to you (never the full link), which kind of place that was — a search engine, a social site, another site, one of our own pages, or nothing at all — and, if you followed a link we ourselves posted somewhere that carries a short marker of ours (for example ?from=show_hn), that marker, which is a name we chose for the post and says nothing about you; an approximate two-letter country, a coarse device class (phone, tablet or computer) plus a broad browser family, and whether the request named itself as a known crawler. That is the whole of it — counts against those labels, never a record of a visit, and only counts for pages we already publish by name (anything else is counted as simply “other”).

Your IP address is never stored. It is used in memory for two things and then discarded: working out the two-letter country (on our own server, from a table that ships with the software — your address is never sent to anyone else), and building a daily de-duplication tag so the same visitor counts as one person that day rather than one per page. That tag is a one-way hash salted with a secret and with the day itself, cannot be turned back into an address, and is deleted within days — which is exactly why we cannot tell a returning visitor from a new one, and cannot follow anyone from one day to the next. The full browser description and the full referring link are discarded in the same breath; neither is ever written down.

The country is approximate and can be wrong (a VPN or a company network moves it), and where it cannot be told it reads “unknown” rather than being guessed. These counts are visible only to the Maintainer.

What we never collect

• IP addresses — never as part of telemetry, and never used to identify you or joined to your telemetry. (Like nearly every web service, the server does briefly count requests per connecting IP address purely for abuse-prevention rate limiting, and keeps routine, short-lived operational request logs; both expire automatically and are never used for profiling or joined to telemetry. The website visit counts described above also read it in memory — for an approximate country and a same-day de-duplication tag — and never store it.)
• User IDs, emails, names, phone numbers, addresses, device IDs, or any other identifier — the PII guard blocks them at both ends. (The one email we ever hold is the one you give us if you create an optional developer account — stored separately, never joined to telemetry; see "Account data" above.)
• Request bodies, response bodies, query strings, headers — none of it is collected, and none of it is uploaded. The one exception is the AI-call meter: to tell repeated prompts apart it reads up to the first 4,096 characters of an outbound request body to an AI provider, inside your own process, and reduces it immediately to a single number — no body text is stored, uploaded or recoverable.
• Raw stack traces, raw error messages, or log lines — a crash report records only a redacted code location (function + file basename + line) plus the error type, and, only if you opt an app into detailed crash mode, the first line of the message and only if it passes the PII guard; never a raw stack, never a value. A health meter that watches logged errors records only how many and how often — never the line, the message, the logger, or the level.
• Command lines, arguments, environments, or output of processes your app spawns — the subprocess meter records only how many spawns happened and how often
• The names of the things meters count — threads, workers, modules, handles, timers, files, pools or queues. A meter reports how many and how long, never which.
• Source code, diffs, file paths, hostnames, environment variables
• Screen contents, screenshots, video, audio

How your connection and our pages are protected

Every connection to Boosthis is HTTPS. Our hosting edge sends a two-year Strict-Transport-Security instruction covering this domain and its subdomains, so a browser that has seen us once refuses to talk to us over plain HTTP again. We deliberately do not send a second copy of that header ourselves: a reader that receives two of them acts on only the first, so adding ours would change nothing and would make the response look malformed to a scanner. We check every day that the instruction is still arriving, and we are told if it stops.

Our pages carry a Content-Security-Policy that forbids any site from framing them, which is what stops clickjacking. The wider policy that describes every script, stylesheet and connection our pages legitimately use runs in report-only mode: the browser does not block on it, it reports to us when a page loads something outside it. It is report-only because our dashboards render scripts and styles inline, and a blocking policy that permits inline code would not be blocking anything. That is an honest limit: a script injected inline into one of our pages would not be reported, while a script loaded from anywhere we do not use would be.

Defense in depth

The same 83-entry PII denylist runs on the client AND on this server. A malicious or out-of-date client cannot bypass the guard by renaming fields — both layers reject the batch on the first hit. The PII guard runs even when the kill-switch (BOOSTHIS_DISABLED=1) is active, so disabling the runtime can never smuggle PII past the chokepoint.

Retention

Full performance samples and cross-runtime traces (the waterfall view) are retained while your install participates in the program — deleted immediately by forget, and by the 60-day countdown after a revocation or suspension; spans are additionally capped per trace so no trace grows without bound. Dashboard snapshots keep only the latest snapshot per app — each upload replaces the previous one. Issue & fix signatures are kept while your install participates in the program — the server keeps one row per install and signature, and repeats just add to a counter; they are not deleted on a fixed schedule or when a rule ships. If you erase your data (forget), issue & fix signatures, crash signatures (with any opt-in detailed fields removed), and learned rules are retained but permanently de-identified — your install ID is replaced with a random anonymous key that cannot be traced back to you (see Part A, Section 7). Aggregated counts with no install ID may be retained longer for trend analysis. Account data (name, email, password hash, sessions, billing status, receipts) is kept while your account is active. You can close your account yourself from Dashboard → Delete account or from the Boosthis phone app — no email to support required. Doing so needs your password and a typed confirmation, ends every other sign-in, cancels any live subscription, and is held for 24 hours first: we email you a link to stop it, and until that window closes nothing has been deleted. Take your data download first if you want a copy (Dashboard → Your data → Download) — after deletion we cannot produce one. When it goes ahead we delete your projects and everything tied to them exactly as forget does, stop your project keys working, remove your sessions, password and payment card details, and strip your name and email from the account record. The only thing kept about a card is a one-way fingerprint that cannot be turned back into a card or a person — it exists solely so the one free trial per card limit still holds after an account is closed. Records we must keep for tax and accounting purposes (payment and receipt records, and the billing name and address on them where a payment was actually made) are retained for as long as the law requires, even after an account is closed. As with forget, learning signals already contributed survive only in permanently de-identified form (Part A, Section 7). Workspace activity-log entries are pruned after a year, support messages are kept while they are useful for handling your request and our records of it, and website security reports are deleted after 90 days. If your access is revoked or suspended, the associated stored data is deleted after the 60-day countdown in Part A, Section 14 (restoring access cancels it; forget is immediate). Short-lived operational rows (sessions, one-time codes, rate-limit counters, checkout working state) expire and are pruned automatically within hours to days. Routine backups of the operational database are kept for up to 30 days and rotate out automatically — data you erase disappears from backups as they rotate. Two exceptions, both narrow. A particular backup is occasionally held past that window when it is the last remaining evidence in an open question about our own records; every hold is recorded with its reason and lifted once the question is answered. And a small, separate copy of the records we are required by law to keep — payment and receipt records — is kept for as long as that obligation lasts and does not rotate out with the rest; it contains nothing beyond those records. Backups are held in a private bucket on Google Cloud, in the United States. Where the service itself runs, and whether anything crosses a border, are two separate answers, both set out under “Where Boosthis runs, and whether your data crosses a border” above; the basis for processing outside the Kingdom is under “Your rights over your data” below.

How to stop reporting / delete your data

Stop the optional full samples: call boosthis.disable_telemetry() / disableTelemetry(). The always-on issue & fix signals keep flowing for registered apps.

Stop everything immediately: set the emergency kill-switch BOOSTHIS_DISABLED=1 in your app's environment. The whole runtime — issue signals included — goes silent at once. The kill-switch always wins.

Delete everything: run boosthis telemetry forget (Python) or npx boosthis telemetry forget (JS). This calls POST /api/installs/forget with your install ID; we delete the install row and every sample, snapshot, trace, and alert tied to it, and permanently de-identify the aggregated learning signals (signatures, resolutions, crash signatures with detailed fields removed, learned rules) by replacing your install ID with a random anonymous key. After erasure nothing we hold can be linked to you or your app. Irreversible. (Per Part A, Section 7, the assignment survives erasure: de-identified learning signals and rules already derived are retained.)

Your rights over your data

Everything you can ask us to do is listed here. Two of these need nobody's permission — they are buttons — and the rest are one message away.

• Get a copy of what we hold about you. Dashboard → Your data → Download, at any time, without asking anyone. It is a machine-readable export of your account and your projects' data. Take it before you close your account: after deletion we cannot produce one.
• Have it corrected. Your account-holder name and email address are editable from your dashboard. For anything else that is wrong, write to us and we will correct it.
• Have it deleted. Dashboard → Delete account (or the same option in the Boosthis phone app) closes your account and deletes your data as described under “Retention”; boosthis telemetry forget erases an install's telemetry immediately, independently of any account. Neither needs an email to support.
• Object to a use, or ask us to stop one. Telemetry can be stopped from inside your own app at any time — disableTelemetry() for the optional full details, BOOSTHIS_DISABLED=1 for everything. For any other use described in this document, write to us and name it; we will stop it or explain why we cannot, and where we cannot you can delete the data instead.
• Withdraw a consent you gave. Consent to this document is asked for again at each new major version, so withdrawing it means declining the new version. The levers above remain available either way.
• Complain. If our answer does not satisfy you, you can complain to the Saudi Data & AI Authority (SDAIA), the supervisory authority for personal data in the Kingdom of Saudi Arabia, or to the data-protection authority of the country you live in.

How to ask, and how long we take. Email support@boosthis.com, or write to the postal address under “Changes & contact” below. We answer within 30 days of receiving a request. If we need something to identify you — normally only that you write from the email address on the account — we will ask for it, and the 30 days run from when we have it. There is no charge. The self-serve levers above are immediate and do not go through this route at all.

Processing outside the Kingdom. Boosthis is operated from the Kingdom of Saudi Arabia. As “Where Boosthis runs, and whether your data crosses a border” above sets out, some of the companies that run it hold what reaches them outside the Kingdom. That processing is necessary in order to provide the hosted service you asked for — there is no version of the hosted dashboard, email or assistant that does without them — and by creating an account or registering a project you agree to it. Each company receives only what is listed beside its name and may use it only for the purpose named there, and for each one we keep a written record of the ground relied on and the safeguards that apply. If you would rather nothing crossed a border, a general install of the toolkit sends nothing anywhere.

Children

Boosthis is a developer tool. It is not intended for users under 16, and we do not knowingly collect data from anyone under 16.

Changes & contact

If we change this document, we will bump the version of Boosthis and note it in the release. Your existing consent remains valid only for the version you opted into. A change to the list of companies under “The companies that can see your data” is announced there in advance, as that section describes. Deleting your account and getting a copy of what we hold about you are both self-serve — you do not need to email anyone. Use Dashboard → Delete account (also in the Boosthis phone app) and Dashboard → Your data → Download. Everything else you can ask for is under “Your rights over your data” above. For any other terms or privacy question, email support@boosthis.com. If you email support, we keep your message (address, subject, and text) so we can reply and keep a record of the request; support mail is never joined to telemetry.

By post: Veqtara Tech Company (trading as Boosthis), commercial registration 7054832287, Rabwa District, Al Noaim Street, Riyadh, Kingdom of Saudi Arabia.