How SPLime handles personal data

Who is responsible

Controller and operator

SPLime is operated by Iastrebov Kirill, an individual operating the SPLime project. No incorporated SPLime company currently exists. Iastrebov Kirill is the data controller for the hosted-service processing described here.

Privacy, legal and general requests may be sent to splime.project@gmail.com.

Scope

What this Policy covers

This Policy covers personal data processed through:

• the public SPLime Landing pages, including commercial-interest and Early Access forms;
• the SPLime Console, account authentication, profiles, teams, Libraries and access administration;
• the hosted spl-server service, daemon/Worker connectivity, synchronization, remote execution, telemetry and artifact delivery;
• the Jupyter plugin and its companion when they connect to SPLime services or a configured managed AI provider;
• product-learning events, security and infrastructure operations; and
• support, privacy and legal correspondence.

Data categories

Information the service can process

• Account and profile. Internal user ID, Google/Firebase provider identifiers, verified email, display name, profile information supplied by the identity provider, SPLime handle, status and relevant timestamps.
• Teams and access. Team and Library names and descriptions, memberships and roles, invitations, access grants and requests, policies, resource references and sharing relationships.
• Credentials and sessions. Credential names, types, owners, subjects, scopes, allowlists, hashes or hints, status, issue/expiry/revocation and usage metadata. Some reusable central credentials are deliberately retrievable by an authorized user; Console session secrets are not persisted as raw secrets on the server.
• Machines and Workers. Machine/Worker identifiers and display names, owner, connection and lease state, capability declarations, runtime/environment compatibility, heartbeat, last-seen, expiry and disconnect evidence.
• Libraries and executable definitions. Library identifiers, slugs, visibility and execution configuration; Objects, Functions, Pipelines, versions, nodes and links; source or YAML definitions; hashes, dependencies, distributions, runtime configuration, provenance and Adapter definitions.
• Runs and artifacts. Selected target, requester, token and resource references, versions, entry points, arguments, keyword arguments, context, status, timestamps, results, errors, event payloads, output streams, artifact names, paths, sizes, hashes and files. What is mirrored depends on the operation and selected telemetry level.
• Managed AI submissions. The explicit instruction and selected notebook/source or product context submitted for a managed action, inclusion/exclusion choices, deterministic facts and hashes, provider/model policy labels, generated result, request status and bounded billing or product-event evidence.
• Commercial interest and consent. Selected offer and plan/price references, account context or encrypted contact email, masked contact hint, keyed duplicate-detection value, request and referral category, consent purpose/version/status, lifecycle timestamps, notification state and withdrawal evidence. The current Coming Soon flow does not collect payment-card details or form a subscription.
• Product learning. Allowlisted event name, time, surface, source, internal actor/account/workspace or short-lived pseudonymous ID, app/catalog version, correlation and bounded categorical properties. Product events exclude source, notebook content, Run payloads, artifacts, free-form text, email, names, handles, raw IP addresses, User-Agent strings, tokens and device fingerprints.
• Security and operations. Audit actions, request and response status, sync results, rate-limit buckets, security events and infrastructure/access/error log data that may include IP address, User-Agent, request path, timestamps and related technical metadata.
• Correspondence. Messages and attachments sent to splime.project@gmail.com, plus the address and other information supplied by the sender.

Why information is used

Purposes and legal bases

The applicable basis depends on the data, action and local law:

• Requested service or contract. Authenticate an account; administer profiles, teams and access; synchronize definitions; connect Workers; execute requested local or remote operations; deliver results and artifacts; and perform an explicitly requested managed AI action.
• Legitimate interests. Operate, troubleshoot and improve a narrowly scoped developer service; maintain compatibility; investigate incidents; prevent fraud, abuse and unauthorized access; enforce access controls; protect users and infrastructure; and establish or defend legal claims. These interests are assessed against affected users' rights.
• Consent. Send the one requested launch notification and, only when separately selected, optional product marketing. Marketing is optional and unchecked by default. Consent may be withdrawn without affecting prior lawful processing.
• Legal obligation. Keep or disclose limited records where applicable law, a valid legal process, tax/accounting duties or other binding obligations require it.

Product-learning analytics is limited to the allowlisted event contract described above. It is used to understand product adoption and failures, not for session replay or an advertising profile.

User choice

Local processing and execution control

• Deterministic notebook analysis can remain inside the configured Jupyter host and companion. It uses supplied in-memory source for static analysis and does not inspect notebook outputs, metadata, the kernel, runtime state or the filesystem.
• Provider-backed AI is a separate, explicit action. The review step identifies included and excluded cells or context before one submission.
• Remote execution necessarily transmits the selected executable definition, required inputs and operation metadata to the server and target Worker. Results, events and artifacts return through the selected path.
• Telemetry is separate from functional execution data. Metadata, diagnostic and full settings mirror different detail; best-effort redaction is not a privacy boundary.
• Before execution or transfer, users should review source, Adapters, dependencies, inputs, target, telemetry level, included AI context and likely side effects.

Public legal pages and ordinary Console pages should never receive a daemon master token or an AI provider secret. The explicit Jupyter credential-management flow can handle reusable central user and Machine credentials; those are different from the daemon master token and provider key.

Managed AI

When a request is sent to OpenAI

Managed AI is default-off and requires a configured server, authorized account, available quota and an explicit user action. The current central path is Jupyter plugin → Jupyter companion → local daemon → spl-server → OpenAI. Provider credentials, the selected model and protected instructions stay at the server boundary.

Notebook Preview sends only the reviewed included cell source, cell identifiers, deterministic facts and integrity hashes; it marks notebook outputs, metadata, runtime inspection and kernel queries as excluded. Other assistant operations can send an instruction and the reviewed operation-specific source, Object catalog, signature, dependency or browser-safe Run context. An opaque safety identifier may accompany the request.

The implementation uses OpenAI's Responses API with store=false, no tools, no background mode and no automatic retry. SPLime's managed-AI endpoints do not write the supplied source or assistant result to feature storage. This does not mean zero provider retention: OpenAI states that API data is not used for model training by default unless the account opts in, while standard abuse-monitoring logs may contain content or metadata and are generally retained for up to 30 days. See OpenAI's current API data controls.

Cancelling before submission prevents the transfer. After submission, cancellation can discard local delivery but cannot guarantee that provider computation, billing or retention stops. Timeouts may leave the outcome unknown. AI output is a draft and can be incomplete, insecure or wrong; it is not automatically written, published or executed.

Devices and requests

Browser storage and infrastructure logs

The Landing stores the selected theme under splime.theme. The Console can use browser storage for its theme, current session state and server token, cached Console data, preview data and UI preferences; short-lived session storage also supports release consistency and onboarding state. Firebase Authentication uses browser-local persistence for sign-in. Signing out removes SPLime Console session and cached data records, but provider-controlled storage may follow provider rules.

The checked-in production configuration uses nginx access and error logs and forwards request-origin information to the API. SPLime and its identity/infrastructure providers may therefore process IP address, User-Agent, request path, timestamps, response status and similar technical evidence for delivery, rate limiting, security and diagnosis. This Policy does not claim that the complete production path collects no IP address or User-Agent.

Public discovery

Public catalog and anonymous run receipts

A deliberately published Object or Adapter has a public profile. It can show the accepted Description, owner and Library identity, verified signature and runtime requirements, immutable public releases, aggregate votes and approximate observed-use counts. The public profile and catalog do not expose source, YAML, distribution archives, voter identities or private Library material.

Embedded execution can send a small, credential-free receipt for an exact public release. A receipt contains only a random event ID, release ID, started or terminal state, coarse runtime family and occurrence time. It excludes arguments, results, artifacts, paths, exception text and stable user, installation or device identifiers. Ordinary network access logs and rate-limit evidence remain separate as described above.

Receipt delivery is best-effort and never blocks local execution. It can be disabled with run_receipts=False or SPL_PUBLIC_RUN_RECEIPTS=0. Public counts are approximate: duplicate event IDs are ignored, raw receipt rows become eligible for deletion after 30 days, and non-identifying aggregate counts may be retained after the raw receipt is removed.

Recipients

Sharing and service providers

Information is disclosed only as needed for the selected service or a lawful purpose:

• Authorized users. Team members, Library recipients, invited users and credential holders can receive information according to the chosen role, grant, visibility and access settings.
• Hosting and infrastructure. Network, server and storage operators supporting the hosted deployment may process request, database, artifact and log data. The repository does not establish a named hosting provider, so none is asserted here.
• Google/Firebase. Firebase Authentication and Google identity endpoints process sign-in credentials, identifiers and profile data. Google states that Firebase Authentication also processes IP addresses and User-Agent strings for security and abuse prevention. See Firebase privacy and security information.
• OpenAI. OpenAI processes only the content and metadata sent by an explicitly requested managed AI action, as described above.
• Google/Gmail. Messages sent to the public contact address are processed through Gmail and related Google services.
• Required disclosures. Information may be disclosed to advisers, authorities, courts or other recipients when reasonably necessary to comply with law, protect rights or security, or handle a legal claim.

User-selected packages, Adapters, Workers, identity accounts and external systems may send information to their own providers. Their terms and privacy practices apply.

Worldwide service

International processing

SPLime is offered worldwide. The operator, users and providers may process data in different countries. Google currently states that Firebase Authentication is operated from United States data centers, and OpenAI and infrastructure providers may process data in multiple locations.

Where applicable law requires safeguards for an international transfer, SPLime will use legally required protections appropriate to that transfer. This statement does not claim a certification, adequacy decision or contractual mechanism that has not been verified for the particular transfer.

Storage periods

Retention and deletion

• Accounts, profiles, memberships and Libraries. Retained while the account or relationship is active and afterwards only as needed to administer deletion requests, resolve shared ownership/access, protect security, maintain necessary backups or meet legal obligations. There is not currently a self-service account-deletion route; requests should be emailed to the address below.
• Firebase Authentication. Google states that most authentication information is kept until the Firebase customer deletes the associated user, after which it is removed from live and backup systems within 180 days; logged IP addresses are kept for a few weeks. Provider policy controls these periods.
• Credentials and sessions. Credentials remain until expiry, revocation or authorized removal, with limited status, usage, security and audit evidence retained as needed. Expired/revoked Console session metadata and associated usage rows are eligible for pruning after 30 days.
• Remote Runs and related artifacts. Current global cleanup cannot remove terminal remote-Run records and aligned events/artifacts before 90 days. Retained descendant lineage, operational settings, failed cleanup, security/legal holds or disabled maintenance can extend retention, so 90 days is not a guaranteed deletion date.
• Mirrored local Runs and Worker snapshots. No exact automated deletion period is implemented for centrally mirrored local-Run telemetry or Worker Library snapshots. They are retained while needed for the service, account, security, legal and operational purposes, and this criterion will be reviewed as deletion controls mature.
• Sync and connection evidence. Sync inbox records are pruned after 30 days. Stale/disconnected connection rows use a configurable period that defaults to 14 days; underlying Machine and credential records are not deleted by that cleanup.
• Commercial interest. Active authenticated and anonymous contact processing uses a 365-day boundary. Expiry or withdrawal revokes active purposes and cancels pending work. Orphaned anonymous protected contact material is cryptographically erased, while append-only consent, operational and security evidence can remain.
• Product-learning events. Raw allowlisted product events are retained for 365 days and then become eligible for pruning.
• Managed AI. SPLime's feature storage does not retain submitted source or the assistant result. OpenAI's provider retention described above may still apply, and bounded quota, status, security or product-event evidence may remain without the submitted content.
• Public run receipts. Raw allowlisted receipt rows become eligible for pruning after 30 days. Non-identifying aggregate public-use counts can remain after those rows are deleted.
• Browser storage. Theme and preference data remains until changed or cleared. Console session/cache records remain until sign-out, expiry, replacement or browser clearing; session-scoped state normally ends with the browser session.
• Infrastructure/security logs and correspondence. No single repository-backed period is established. Records are kept only as long as reasonably needed for operations, security, support, legal requests and claims, subject to provider and legal requirements.

Deletion can be delayed by backups, another user's rights, shared-resource integrity, fraud/security investigation, audit evidence, legal claims or a binding retention duty. When full deletion is not required or technically possible, access may instead be restricted or identifying material minimized where appropriate.

Requests

Your privacy rights

Depending on applicable law, a person may have rights to be informed; access and receive a copy; correct inaccurate data; request deletion or restriction; obtain portable data; object to certain processing; withdraw consent; and complain to an appropriate supervisory or regulatory authority. These rights can be limited by lawful exceptions and the rights of others.

Send a request to splime.project@gmail.com. Include enough information to identify the relevant account or request, but do not email passwords, access tokens, daemon master tokens or provider secrets. Identity may be verified before a request is fulfilled. No data protection officer or particular supervisory authority is designated because none has been established for this project.

For an overview of EU data-protection rights, see the European Commission's official guidance.

Age limit

The hosted service is for adults

The SPLime hosted service is available only to persons aged 18 or older and is not directed to children. If you believe a minor supplied personal data, contact splime.project@gmail.com so the report can be investigated and appropriate action taken.

Safeguards

Security

SPLime uses safeguards appropriate to the current service, including TLS deployment configuration, authenticated sessions, role/scope and grant checks, credential hashing where retrieval is not required, application encryption for anonymous commercial contacts, request limits, narrowly validated event/provider payloads, server-side AI provider secrets, audit evidence and restricted artifact paths.

No system is completely secure. SPLime does not claim an external certification, independent audit, guaranteed encryption of the entire database or artifact store, or immunity from loss or unauthorized access. Users should protect accounts and Workers, keep backups, use least-privilege credentials, and report suspected compromise promptly.