Purlo

1. What this policy covers

This policy explains how Purlo handles information in the hosted service and in a self-host installation. Purlo is an SEO and answer visibility product. A business can connect a website, provide its own documents, inspect the questions buyers ask, and review whether AI assistants and Google recommend that business. The service is built around an evidence chain, so the records behind a result matter as much as the result itself.

The word Purlo means the Purlo software and the service operated by the person or organization that gave you access. The operator may run the hosted service, or may provide a self-host package for your own machine. If your organization has an agreement with a specific operator, that agreement may give you a contact address or additional privacy terms. This page describes the data behavior of the software and does not add a compliance certification or a promise that the software is appropriate for every regulated use.

2. Information you give Purlo

An account currently needs an email address and a password. Purlo stores the email address so the account can be identified. It stores a password hash rather than the password itself. The hosted application also stores a session record and uses an httpOnly session cookie named purlo_session to keep a signed-in browser connected to the account. The cookie is used for authentication, not for advertising or cross-site profiling.

An account can own projects. A project can include a domain, project settings, market and language choices, and the records needed to run work for that project. Every project record is scoped to its project so one account cannot read another project's records through the normal application queries. Purlo also stores records needed to process jobs, preserve their status, and show whether a job completed, failed, or needs to resume.

When the product is used with source material, it stores crawled page content and the page URL. It can also store documents uploaded by the account, document content, file metadata, and the relationship between a document and the project that supplied it. Upload only material that you are allowed to provide for this purpose. Purlo does not transfer ownership of your website, documents, or brand facts to the service.

3. Evidence records and generated work

Purlo stores prompt text because the exact question is part of the evidence for an answer. It stores the raw answer text returned by an AI provider, the provider surface and model used, the time of the run, and the source URLs that can be associated with the answer. Raw AI answers are immutable evidence records. Later evaluation does not overwrite them. It creates new records beside them so a result can be traced back to the original prompt and answer.

The application can also store evaluation results such as a resolved mention, a citation, a defensible position, an eligibility outcome, or an explanation of why a run was not counted. A failed request, timeout, rate limit, safety refusal, parse failure, or AI Overview non-trigger is recorded as an outcome rather than silently turned into a zero. This lets a person distinguish missing evidence from evidence that says a business was not mentioned.

Purlo logs product events and AI calls for debugging and operations. An AI call log can include its purpose, provider, model, prompt hash, outcome, latency, token counts, cost fields, and an error class when those values are available. A prompt hash helps identify a request without making the audit row a second copy of the full prompt. Generated content is restricted to approved brand facts, and the product records the checks that block a forbidden or unsupported claim.

4. What leaves a hosted Purlo server

To produce an AI answer, the hosted service sends prompt text and the relevant page or document content to the configured AI provider. In the first implementation, that request travels through the Sider bridge. The provider processes the request under its own terms and returns answer text to Purlo. Purlo stores the returned raw answer as evidence and keeps the provider and model information with the run. Do not upload a secret, password, access token, or other material that should not be included in an AI request.

The hosted service also uses the infrastructure required to run the application, database, queue, and cache. Account, project, source, evidence, job, event, and AI-run records must be sent to or stored in that infrastructure for the service to work. Purlo does not sell this information and does not send it to an advertising network. The exact infrastructure provider can depend on the installation operated by your service owner.

Google Search Console and Google Analytics 4 connections are planned for the later Search Console and GA4 feature. When that feature is enabled, Purlo will request read-only tokens and use them to read demand, query, position, or analytics data that the account has authorized. Those tokens and returned data will be handled as project data. Purlo will not claim that a Search Console or GA4 connection exists when it has not been connected.

5. Self-host mode

Self-host mode is designed for a buyer that wants to run the application, database, queue, and stored evidence on its own machine or network. In that mode, the Purlo hosted service does not receive a copy of the buyer's account data, crawled pages, uploaded documents, prompts, raw answers, or logs. The buyer controls the machine, the backups, the access policy, and the retention settings for that installation.

A self-host installation may be configured with the buyer's own AI provider keys. If it sends a prompt or page content to an external AI provider, that provider receives the request because the buyer selected it. That is an external call made by the buyer's installation, not a copy sent to Purlo. The buyer must review the selected provider's terms and configure the installation to meet its own security requirements. If the buyer keeps the AI provider local, the material can remain on the buyer's machine.

Self-host mode can also connect to Google services if the buyer enables the relevant integration. The same boundary applies: a token and the data returned by Google are held by the buyer's installation, and Purlo does not receive them. The buyer is responsible for protecting credentials, restricting access, applying updates, and deleting local backups when it wants the data gone.

6. How Purlo uses information

Purlo uses account information to authenticate access. It uses project and source information to crawl or read the material you supplied. It uses prompts, provider responses, and source URLs to measure visibility, diagnose competing recommendations, preserve evidence, and show the basis for each number. It uses approved brand facts to generate content that is constrained by the facts you selected. It uses event and AI-run logs to find failures, investigate support requests, and understand whether a provider call succeeded.

Purlo does not use your private documents or raw answers to create a public profile of your business. The hosted operator may need limited access to records to operate the service, respond to a support request, secure the system, or comply with a lawful request. Access should be limited to that purpose. If the operator wants to use your content for a different purpose, it should ask for permission or provide a separate notice.

7. Retention and deletion

Hosted Purlo records are kept while the account and its projects are active, because deleting a prompt or raw answer too early would break the evidence chain. There is no promise in this policy of a universal fixed retention period for every installation. A service operator may have operational retention rules that apply to logs, queues, backups, and inactive accounts, and those rules should be disclosed when they differ from this description.

You may ask the service operator to delete your account and project data. A deletion request should identify the account and project clearly enough to prevent deletion of the wrong tenant. The operator will remove the requested records from active application storage when the request is accepted. Copies in encrypted backups, disaster recovery media, or security logs may remain until those systems rotate or are securely overwritten. Records that must be retained for a legal, fraud prevention, or security reason may be kept for that limited reason and then deleted.

In self-host mode, the buyer or local administrator controls deletion. Purlo cannot delete a local database or a local backup on the buyer's behalf. Deleting a project can remove the evidence that supports historical numbers, so export anything required for an internal record before requesting deletion.

8. Security and your responsibilities

Purlo uses password hashing, scoped project queries, session protection, input validation, and audit records as parts of its security design. No internet service can promise that an unauthorized person will never access data. You are responsible for choosing a strong password, protecting access to the account, reviewing who can reach a self-host installation, and removing credentials that are no longer needed. Tell the operator promptly if you see an unfamiliar sign-in or a source that you did not connect.

Purlo is not a secure document archive for every category of sensitive information. Before connecting a source, decide whether its contents are suitable for the AI provider and infrastructure used by the installation. Redact secrets and personal information that the product does not need. The service owner may ask for enough information to investigate an incident, but do not send a password or an unredacted secret in a support request.

9. Questions and policy changes

For a hosted account, use the support or account contact supplied by the operator that gave you access. Include the account email, the affected project, and a short description of the request. Do not include a password or a full private document in the first message. For a self-host installation, contact the person or team that administers that installation.

Purlo may update this policy when the service changes. The current version will be published at this page with a new effective date. A material change should be explained through the account or service channel available to the operator. Continued use after the effective date means the updated description applies to future activity. Nothing in this policy removes rights that apply under the law governing the account or the operator.