Skip to main content

Privacy and Data Submission Guidance

Evidence boundary: This page is not a complete operator privacy policy or a contractual statement about every TeaQL-hosted service. The repository verifies the website analytics behavior described below, but it does not establish hosted-service retention periods, processing locations, subprocessors, deletion SLAs, or controller/processor terms. Obtain those terms in writing before sending confidential, personal, or regulated data.

Documentation Website Analytics​

The current site implementation:

  • displays an Accept/Reject analytics choice when no stored preference exists;
  • stores accepted or declined under the browser local-storage key teaql-analytics-consent;
  • loads Google Analytics measurement ID G-DB9JTWZN9Q only after acceptance;
  • sends the current page path, including URL search and hash components, when configuring the analytics page view;
  • does not load the analytics script after rejection in that browser state.

Do not place secrets, personal data, model contents, or customer identifiers in documentation-site URLs. To revisit the choice, clear the site's local-storage entry and reload the page; the current UI does not expose a separate preference reset control.

This behavior is verified from the site root implementation. Google's own processing terms and controls remain external to TeaQL.

Hosted Generation and Evaluation Requests​

The Maven and Cargo clients can send model inputs and request configuration to TeaQL service endpoints for evaluation or generation. Error reports may also contain model names, field names, paths, and diagnostic details.

Before sending a request:

  1. Confirm the resolved endpoint with client help/configuration.
  2. Inspect the model and diagnostic payload for secrets or regulated data.
  3. Prefer synthetic names and fixtures.
  4. Do not upload production databases, credentials, private keys, tokens, payment data, health records, identity documents, or customer records.
  5. If sensitive submission is required, obtain written terms covering purpose, roles, security, location, retention, deletion, subprocessors, incident handling, and support access.
  6. Preserve only redacted configuration/help output; client show-config can reveal a locally stored API key.

The built-in free-tier API key means no additional key setup is required for normal generation. It does not change the payload-classification responsibility.

Self-Hosted Runtime Boundary​

Running TeaQL code in an organization's own environment does not by itself send application database records to TeaQL. A separate client call, support upload, external tool, telemetry integration, or hosted endpoint can create a new data flow and must be reviewed independently.

The deploying organization remains responsible for its databases, logs, audit sinks, backups, access control, retention, deletion, residency, incident response, and downstream processors.

Information Required from a Hosted-Service Agreement​

Do not infer these terms from this documentation site:

  • legal operator and contact details;
  • controller/processor roles and processing purposes;
  • categories of submitted data and telemetry;
  • processing and backup locations;
  • subprocessors and cross-border transfer mechanisms;
  • security controls and support access;
  • retention and deletion periods;
  • data-subject and incident-response procedures;
  • training or product-improvement use;
  • service-specific opt-out and account-deletion mechanisms.

Contact and Safe Default​

The site footer publishes hello@teaql.io as the general contact. Until a service-specific privacy policy or agreement answers the items above, use synthetic, non-confidential examples and do not submit regulated data.

This page is technical data-flow guidance, not legal advice.