Privacy Policy

Who and what this policy covers

This proposed policy covers the Not Organic website and shared account, authorization, billing, and hosted-service layer. The current operator is Keith Abiola Noel, a sole proprietor in Québec, Canada, using the proposed, unregistered name Not Organic. The public business mailing address and verified privacy contact remain to be added before adoption.

Connected products can collect additional information for their own features. Their notices should explain that processing. This page does not claim that every document, message, relationship record, or learning record lives in the shared account layer.

For account administration, security and billing, Not Organic determines the purposes of its own processing. For customer content processed on an organization's documented instructions, the relevant service may instead act as a processor or service provider under a separate data-processing agreement. The role depends on the actual activity; calling a product a platform does not decide that role. An organization managing your workspace may set access and retention policies, which it must explain to you.

Information processed by the shared service

A payment provider collects the payment details needed for checkout. Not Organic receives transaction and entitlement information rather than handling your full card number through its own checkout form. The current billing integration also sends an account identifier and product information to associate a purchase with the correct account.

Why information is used

The purposes are to deliver requested features, authenticate accounts, apply permissions, maintain balances, process purchases, support users, prevent abuse, investigate incidents, and meet legal obligations. Processing should be limited to information reasonably needed for those purposes.

Where consent is required, it must be meaningful and relate to the processing being proposed. Optional features, especially those involving audio, video, or sensitive information, should explain what will be sent and obtain any required permission before transmission. You can decline an optional feature, though that feature may then be unavailable.

For people protected by laws requiring a specified legal basis, the adopted policy must identify the applicable basis for each purpose, such as performing a contract, consent, legal obligation, or a permitted legitimate interest. It must not treat acceptance of terms as consent to unrelated processing.

AI providers and sensitive content

A hosted AI request passes through the gateway and the selected routing or model provider. Those services need the request content to perform the requested task. The gateway substitutes a pseudonymous usage identifier for direct account identity on its inference path, but the content of a prompt can still identify you or someone else.

Do not assume an AI request is end-to-end encrypted from the service operator or invisible to the selected provider. Encryption at rest and protected transport serve different purposes. Provider retention and training terms depend on the configured provider and agreement; this policy does not promise universal zero retention or “never used for training.”

Only submit sensitive information when necessary for the feature and when you have authority to share it. Product notices should explain any use of information to personalize or evaluate AI behavior, and any separate research or model-improvement purpose, before that use occurs.

Hosted code execution

When you request hosted execution, the service sends your code, execution settings, account and product identifiers, and project identifier to the configured execution provider. Results can include standard output, errors, status, and generated artifacts. Code and output may contain personal information or secrets that you include; do not put passwords or private keys in source code or logs.

Execution is scoped to the requesting account, application, and project. Sandbox isolation does not make the code invisible to the service operator or execution provider. Run records and artifacts have their own retention arrangements; the 30-day stored-response expiry below does not apply to them.

Memory, personal models, and organization models

Personalization may use saved context or retrieval without changing model weights. Model training is a separate operation that may use selected examples, corrections, preferences, evaluation data, and derived adapters or checkpoints. A personal model and a model shared within an organization have different audiences and disclosure risks. A purchase or general sign-in is not, by itself, notice of or permission for all of these uses.

Before an optional training service is enabled, its notice must identify the data selected, purpose, recipient providers, audience, administrator access, retention, and available controls. Any required consent must be separate and meaningful. An organization must have authority to supply information about workers, customers, or other people; an administrator's preference alone does not establish that authority. Use for unrelated customers or general model improvement requires its own disclosed legal basis and any required consent.

Deleting source records does not necessarily remove learned information from an existing model. Training arrangements must explain when an adapter can be deleted, retired, or retrained, and how a privacy request will be handled. We do not promise automatic machine unlearning. A trained model can expose sensitive information, so access controls and evaluation are needed as well as a privacy notice.

Service providers and other disclosures

The shared service uses Railway for hosting and Convex for application records. OpenBao is software we operate for encryption-key operations; naming it does not mean a separate OpenBao company receives your information. Configured routing and model providers process hosted inference requests. Depending on the enabled feature, it can also use Paddle for purchases, PostHog for operational analytics, object-storage services for artifacts, and Cloudflare for hosted code execution, Sprites for other execution features, or Tavus for video features when those integrations are enabled.

This is an explanation of the service categories and supported integrations, not a statement that every provider receives every user’s data. Provider access depends on the feature, configuration, and information needed to supply it. The adopted policy should link a maintained provider list with processing locations and purposes.

We may also disclose information when you direct us to, where required by law, or where lawfully necessary to protect people, investigate abuse, or defend legal rights. A business transfer involving personal information must preserve applicable privacy obligations and include any required notice.

Data may be processed outside your province or country and be subject to the laws there. The adopted policy must describe relevant transfer safeguards rather than promise local-only storage.

Cookies, preferences, and analytics

The account portal stores a notorganic_appearance preference cookie for up to 30 days across Not Organic subdomains. It remembers only the selected product appearance and light or dark theme, so sign-in can match the product you came from. It does not contain an account identifier or authorize access. You can change the appearance in the portal or clear the cookie in your browser.

The public site’s theme control follows your device preference and keeps a manual change only for the current page. The current theme script does not store a persistent preference or set an analytics cookie.

The account portal uses an essential, opaque session cookie, configured for up to 14 days, and short-lived authorization state. In production, the session cookie is protected with Secure, HttpOnly, and SameSite settings. Blocking essential cookies may prevent sign-in.

When gateway analytics is configured, its event payloads include a pseudonymous account identifier and operational metadata such as usage quantities, costs, and outcomes. The telemetry implementation does not place prompt bodies or direct decentralized identifiers in those analytics events. Pseudonymous information can still be personal information.

Additional optional tracking or marketing must be disclosed and use any consent controls required by law. A browser theme setting is not an analytics-consent setting.

Retention and deletion

Retention depends on the purpose and record type. The following describes the implemented defaults; it is not a promise that every backup or external provider deletes on the same schedule.

Stored AI responses

The gateway’s Responses API stores responses by default. Its current storage adapter encrypts them and assigns a 30-day expiry. A supported request with store: false avoids that gateway response record; it does not erase usage records or control an upstream provider’s retention.

Sessions and authorization

Portal sessions expire after up to 14 days. Optional device sessions have a 30-day lifetime in the current implementation. Expiry invalidates access; cleanup of stored records can happen separately.

Billing, security, and account records

Keep only as long as necessary for the identified purpose, including legal recordkeeping, fraud prevention, and disputes. The adopted retention schedule must state the applicable periods and backup handling.

Documents, artifacts, and product data

Retention depends on the feature and storage location. The 30-day Responses API default does not apply to all product data, execution artifacts, or files.

Where supported and authorized, deleting an individual stored response removes that gateway record. Account closure is broader and needs its own process. We should explain any information retained, why it is retained, and any limits on deleting independent recipients’ copies.

Your choices and requests

You can ask for access to your personal information, correction of inaccurate records, an explanation of processing, withdrawal of consent where applicable, and deletion or portability where the law provides it. Depending on where you live, you may also have rights to object, restrict processing, or appeal a decision.

Use the support channel in your product to request help while the dedicated privacy contact is being finalized. Describe the request and relevant account without sending passwords, private keys, or full payment-card details. Identity checks should be proportionate to the request.

We will respond within the time required by applicable law, explain any lawful refusal or extension, and request only information reasonably needed to verify and handle your request. A request may affect a feature that depends on the information, but asking to exercise a right should not itself lead to unfair treatment.

You can raise a privacy concern with the authority responsible for your location. In Québec, you can contact the Commission d’accès à l’information du Québec. The Office of the Privacy Commissioner of Canada also explains complaint options under the laws it administers.

Depending on the law that applies and the processing involved, requests may include access, correction, deletion, portability, restriction, objection, and withdrawal of consent for future optional processing. Some records may need to be retained for another lawful purpose. We will explain the scope of a request and applicable exceptions, and verify identity proportionately without asking you to send passwords or API keys. You may also complain to the relevant privacy regulator.

AI suggestions should not be treated as final decisions about employment, education, credit, health, or other significant interests. Any feature intended to make a solely automated decision with a legal or similarly significant effect requires a specific notice and the safeguards required by applicable law before it is offered.

Security and identity portability

The shared layer uses scoped authorization, device-bound proofs, access controls, and encryption for stored response content. These measures reduce risk; they do not eliminate it. We will assess confidentiality incidents, take appropriate steps to limit harm, and notify affected people and authorities when required by law.

AT Protocol identity and public records have different visibility from private account and billing records. Public identifiers or records may be discoverable or replicated by independent services. Moving an identity does not automatically move every connected product’s private data or erase previously shared public records.

A Personal Data Server (PDS) is not a guarantee that everything stored there is private. Public AT Protocol records can be indexed, copied, and retained by independent services. Private prompts, billing records, credentials, and training material must not be treated as public merely because an account uses a decentralized identifier. Moving your identity, exporting a workspace, and exporting model artifacts are separate operations with different technical and licensing limits.

Children and product-specific information

Products serve different purposes and may have different minimum ages. A learning feature and a dating feature cannot be treated as having the same eligibility or privacy needs. The adopted policy and each product’s onboarding must state the applicable ages, parental-permission process where relevant, and treatment of children’s information.

If you believe a child has supplied information contrary to a product’s rules or without required permission, contact the product’s support channel so it can be investigated.

Changes and accountability

The adopted policy will carry an effective date and identify a person or team accountable for privacy. Material changes should be communicated appropriately, and a new purpose requiring consent must not be introduced solely by changing this page.

This review copy is based on the service implementation and published privacy principles. The final operator identity, contact, age policy, provider arrangements, retention schedule, and regional rights details still need confirmation.