DRAFT — not effective. Part A is based on inspected application code, not a live infrastructure audit. Part B is a launch template and must not be published as a statement of current practices until its decisions and controls are verified.
Effective: Not effective — draft preview
Jolts Inc. (“Operator”, “we”, “us”) operates Jolts. Our address is [Business address: to be confirmed]. Privacy questions and rights requests may be sent to contact@jolts.xyz. [DECISION: confirm this mailbox is monitored and designate a privacy owner; identify any legally required representative or privacy officer.]
Part A — website visitors and business enquiries
Information collected
When you send an enquiry, we receive your name, work email, any company or website you provide, your selected business interest and campaign goal, your message and your permission to be contacted about it. The application can also record which site placement led to that form, such as the homepage or resources section. These source labels are not proof of comprehensive acquisition tracking.
The website and its infrastructure may process request information needed to serve and secure it, such as network address, requested URL, time, browser and error information. [VERIFY: actual application, hosting, proxy and security log fields, providers, locations and retention before publication.] Do not claim that request logs are anonymous merely because the enquiry fields are filtered from Rails parameter logs.
If you choose a theme, the application stores that preference in a first-party cookie. Operational session or request-security mechanisms may be used for forms. See the Cookie and Storage Notice for the verified inventory and controls.
The inspected website does not include third-party advertising or analytics scripts. This is not a promise about unverified infrastructure, later releases or other properties. Any new non-essential tracking requires a new assessment, accurate notice and working choices before activation where required.
Purposes
We use enquiry information to understand and respond to your request, evaluate potential business fit, maintain records of that discussion, and protect the form against abuse. We use operational information to deliver content, diagnose faults, protect systems and maintain preferences. We may preserve relevant information to meet applicable legal obligations or establish, exercise or defend legal claims.
Permission to answer an enquiry is not a general newsletter or advertising subscription. We will obtain and record any additional permission required for separate promotional communications and provide a practical opt-out.
Legal bases where relevant
[DECISION: applicability and basis must be confirmed per jurisdiction.] Where a legal-basis explanation is required, responding to a request made by an individual may involve steps requested before entering a contract; handling a business representative's enquiry may involve a documented legitimate interest in business communication. Security and legal obligations require their own assessment. Do not use “contract” as a blanket basis for every visitor or publisher end user. Where processing depends on consent, explain the choice, record it and allow withdrawal without affecting the lawfulness of earlier processing.
Disclosures and vendors
Access should be limited to people and providers who need information for the stated purposes, under appropriate confidentiality and contractual safeguards. Potential functions include hosting, database management, support, business communications and professional advice; the actual recipients and countries must be inventoried before this notice is published. Do not list a provider as used merely because its SDK, configuration or deployment template exists.
We may disclose information when lawfully required, to protect legal rights or security, or as part of a genuine corporate transaction subject to appropriate notice and safeguards. Such clauses do not authorize unrelated monetization of enquiry data. [VERIFY and state the actual treatment of sale, sharing and cross-context advertising under applicable law; do not publish an untested “never sell or share” assurance.]
Retention and deletion
Retain information only as long as necessary for the identified purpose and applicable obligations. [DECISION: approve concrete periods or intelligible criteria for unanswered enquiries, active discussions, closed opportunities, logs and backups; implement deletion and legal-hold procedures.] The current code does not establish an automated enquiry deletion schedule. Do not promise that information is automatically removed after a period that is not enforced.
Deletion may require different handling for active systems, backups and records subject to a lawful hold. State actual backup expiry and restoration safeguards. Retaining minimal records of a rights request or suppression preference may be necessary to honour the request and show compliance.
International processing
[DECISION: identify actual storage and access countries.] Where information is transferred internationally, identify the applicable safeguard or basis, how to obtain relevant information, and any required representative. An encrypted network connection or a vendor's generic compliance statement is not itself a transfer mechanism. Do not claim data residency without checking support, logs, backups and subprocessors as well as the primary database.
Security
We apply safeguards appropriate to the risks and the actual service. [VERIFY: access control, encryption, patching, backups, personnel access and incident handling against the security schedule.] No internet service can guarantee absolute security. This statement does not disclaim mandatory security duties. Do not publish certification, penetration-testing or response-time claims without current evidence of their scope and validity.
Your choices and rights
Depending on applicable law, you may have rights to request access, correction, deletion, a copy or portability, restrictions on processing, withdrawal of consent, or an objection to particular uses. Some jurisdictions provide opt-out rights for certain advertising, sale/sharing or profiling, and an appeal process. [DECISION: state the actual applicable rights and implement their workflows and deadlines.]
Contact contact@jolts.xyz with enough information for us to locate the relevant records. We may proportionately verify identity or authority; do not send identity documents or conversation histories unless a secure process specifically requests them. Where a request must be handled by a publisher or another controller, we will identify the appropriate route rather than misrepresent our ability to act. We will explain a lawful refusal or limitation and available appeal/complaint routes. Requests should not require creating an account that otherwise does not exist. You may contact the applicable privacy regulator without first waiving any rights or remedies.
Children and public content
This website is directed at business evaluation. [DECISION: approve the intended audience and handling of information from minors.] A business-account age limit does not resolve whether a future publisher's users include children. Notify us if you believe information about a child has been submitted inappropriately so it can be assessed and handled under applicable law.
Public articles and demos may be accessible to search engines and automated readers. Do not include personal or confidential information in material intended for public publication. Enquiry records are not public content endpoints.
Part B — platform processing schedule, not yet effective
This part must be completed for the actual service before enabling advertising, tracking or storage of conversation text. It must identify which activities apply to each audience and property rather than suggesting that every category is collected from every user.
Audience-specific data inventory
| Audience / activity | Candidate categories to verify | Purpose and necessary limits |
|---|---|---|
| Business account users | Name, work contact, role, account and authorization records | Manage access, contracts, support and security |
| Advertisers/agencies | Campaign settings, budget, creative, destination, billing records | Deliver authorized campaigns and reconcile charges |
| Publishers | Property and integration details, placement rules, settlement records | Operate approved placements and pay agreed earnings |
| Publisher end users | Permitted context fields, request/event identifiers, coarse context where authorized | Match and measure a placement under the approved data schedule |
| Conversation storage | Exact content fields, source, redactions, access and retention | A separately specified necessary purpose; never “all conversations just in case” |
| Tracking | Actual identifiers, SDK/device storage, events and cross-property linkage | Describe each use and required consent/opt-out handling |
| Poll participants | Voluntary answer and permitted event metadata | Report the stated poll purpose without collecting prohibited sensitive details |
| Payments | Actual payment-provider references, tax and settlement information | Billing, fraud prevention, accounting and legal duties |
[DECISION: remove unused categories; specify real retention and recipients per row. Determine whether payment details reach the Operator or remain with the payment provider. Do not claim the Operator never receives card data without checking the integration.]
Roles, purpose boundaries and recipients
A publisher's instructions may make the Operator a processor for a specified activity. The Operator may be a separate controller for its own billing or legal records. Independent reuse of end-user data for network optimization, profiling, training or new purposes requires separate analysis; a processor contract does not make such reuse authorized. Joint determination of purposes may require a joint-controller arrangement. Complete the DPA role matrix before publishing a simple “we are only a processor” statement.
Describe what advertisers receive: for example approved aggregate campaign reports, permitted conversion events or expressly consented leads. Do not disclose raw user conversations or identifiable poll answers to advertisers by default. [DECISION: specify the real reporting granularity, aggregation safeguards and contractual recipient restrictions.] State how publishers and users can understand the sponsor, placement basis and available controls.
Sensitive context, children and user choices
The proposed default is to exclude sensitive personal information and child-directed inventory from advertising until explicitly assessed and supported. This is a proposed product boundary, not a factual claim that detection is perfect or a substitute for legal analysis. If context contains health, financial, sexual, political or other sensitive details, do not assume its presence in a chat makes its use for advertising permissible.
Document how publisher signals reach the API, which choices block processing, how withdrawal and opt-out propagate, how preference signals are honoured where required, and what happens when permission is missing. Missing permission must not silently be treated as consent. Define retention of consent evidence and suppression records without collecting unnecessary identity information.
Training, profiling and future changes
[DECISION: explicitly choose whether any data is used for model training, cross-app profiles, independent audience building or third-party model services.] These uses must not be implied by a broad operational licence or hidden behind “improving services”. A processor-only scope excludes independent reuse unless a separate lawful arrangement is established. Any selected use needs intelligible notice, compatible purpose/basis, recipients and working choices.
When the actual practices change, update this notice and deliver required notices or choices before beginning materially different processing. Keep prior versions and the effective date. Contact: contact@jolts.xyz.