File Privacy

You retain ownership of everything you upload. We do not acquire rights in your files by hosting them, and we do not license them to anyone. We process them for one purpose: to operate the research features you are using, on your instruction.

Under data-protection law we act as the controller for the account data that identifies you, and as a processor acting on your instructions for the contents of the files you upload. The lawful bases we rely on are performance of our contract with you (operating the service you asked for) and our legitimate interest in keeping the platform secure and available. Where consent is the applicable basis in your jurisdiction, uploading a file is the act of consent, and deleting it withdraws it.

You are responsible for having the right to upload what you upload. Section 13 sets out what that means in practice, including material we ask you not to place in the library at all.

Everything the library holds, where it lives, and how long it survives. Classification follows the scheme in our Cybersecurity Policy.

Each step names the control that applies to it, so a reviewer can trace an assurance to the point in the system where it is enforced.

• Upload. Your browser sends the file over an encrypted HTTPS connection to our authenticated API. It does not upload to storage directly, which is why no browser ever holds a credential that can write to the storage bucket. The server reads a bounded amount and rejects anything above the size limit rather than buffering it.
• Admission. The file is attributed to your account, given an identifier, and written to a storage path derived from your account id and that identifier. The filename is sanitised before it can become part of a storage key.
• Processing. Text is extracted and split into passages; images and PDFs get preview thumbnails. Derived Artifacts are written to the same account-scoped path. A bounded excerpt is indexed so you can search your library by content.
• Retrieval. Opening or downloading a file authenticates you, confirms the file belongs to your account, and only then mints a short-lived signed link. Your browser streams the bytes from storage directly.
• Use in research. A file is only sent to a model when you attach it to a question. Section 9 covers exactly what leaves our systems and under what terms.
• Deletion. Deleting moves the file to Trash, where it stays recoverable for 30 days, after which an automated job purges the original, every Derived Artifact and the metadata row.

In transit. The platform is served exclusively over HTTPS using industry-standard TLS, and every internal hop between our services and cloud storage is encrypted as well. Files are never carried over an unencrypted connection, and they are never handed to a third-party upload widget on the way through.

At rest. Every object we store — the original file and every Derived Artifact — is encrypted with AES-256 using Google-managed encryption keys, applied by the storage service before data is written to disk. File Metadata sits in a managed PostgreSQL database that is encrypted at rest and has no public IP address: it is reachable only from inside our private network. Database backups are encrypted with the same protection as the primary.

We do not offer customer-managed encryption keys (CMEK) or bring-your-own-key for library files today. If your review requires them, contact us before uploading.

Library files are written to a private cloud storage bucket, separate from the public assets that serve our website. The bucket is configured with public access prevention enforced and uniform bucket-level access, which means permissions are granted through IAM alone and no per-object access-control list can be attached — not by us, and not by a mistake in code. An object in that bucket has no URL that works without authorisation.

Within the bucket, every object is filed under a path derived from your account id and the document id, with the original and all Derived Artifacts under the same prefix. Two properties follow from that layout, and both are enforced server-side:

• A request can only address objects under the prefix belonging to the requesting account. There is no code path that composes a key from user input alone.
• Filenames are sanitised into a single safe path segment before they can become part of a key — directory separators, relative segments and leading dots are removed and the length is bounded. A crafted filename cannot escape its folder or reach another account’s object.

File Metadata and folder structure live in a managed PostgreSQL database with no public IP address, reachable only across our private network. Every query that reads or writes a file record is scoped by account, so isolation is enforced where the data lives rather than in the browser or in a UI filter.

Files are stored in the United States. We do not currently offer a choice of storage region for library files.

Your library is private by default. There is no sharing switch, no public link, no "anyone with the link" mode, and no team or organisation visibility. Another Amaltash user cannot browse, search or open your files, and nothing you upload is exposed by publishing a strategy to the marketplace.

Requests against the library are logged with the identity that made them, the operation, the time and the outcome. Those records are exported from our cloud logging into a dedicated archive bucket with a retention policy measured in years, so an audit trail survives long after the operational log window closes. As stated in section 3, logs capture the shape of a request, never file contents.

Application errors and latency are monitored continuously, with alerting on failure conditions. Storage and database access are additionally covered by our cloud provider’s own audit logging.

To make a file useful, we extract its text, split that text into passages, and generate preview thumbnails for images and PDFs. That processing happens on our own infrastructure, and the results are stored under the same account-scoped path as the original.

Nothing is sent to a model until you attach it to a question. When you do, the extracted text of that file (or, for an image, the image itself) is included in that request to the AI provider that answers it. Two bounds apply and are enforced before the request leaves us: a per-file limit of 80,000 characters and a per-question limit of 200,000 characters across all attached files. The product tells you when a file will be trimmed by these limits. A file is included once per conversation and then replayed from that conversation’s history rather than re-sent.

AI providers receive that content under commercial API terms which prohibit them from using content submitted through the API to train their models, and require them to process it only to return a response. We do not use your files to train models, we do not use them to improve the service for other users, and we do not use them for advertising or profiling.

Your files are never shown to other users, never added to a shared or public dataset, and never attached to a strategy you publish.

We use a small number of vendors to operate the library. Each is bound by contract to confidentiality and security obligations, and each receives only what its function requires.

We do not sell your files or your file metadata, and we do not share them with data brokers, advertisers or analytics networks. A current list of sub-processor categories is maintained in our Privacy Policy; vendor security requirements are set out in our Cybersecurity Policy.

Deleting a file moves it to Recently Deleted. It leaves your library immediately and stops being available to your research sessions, but it remains recoverable by you for 30 days. Deleting a folder does the same for everything inside it. You can also delete a file forever from Recently Deleted, which skips the waiting period.

After 30 days, an automated job purges the file. The purge removes the original object, every Derived Artifact and the database record — not merely the entry you saw in the app. The storage bucket does not keep prior object versions, so a purged object leaves no earlier generation behind. The job is idempotent and re-runnable, so a transient failure results in a retry, never a silently skipped file.

Within the product you can, at any time and without contacting us: list and search everything you have uploaded; download any original file; restore anything in Recently Deleted; delete a file or a whole folder; and delete a file permanently.

Depending on where you live, you may also have statutory rights to access, correct, export, delete or restrict processing of your personal data, and to object to it. Those rights, and how to exercise them, are described in our Privacy Policy. They apply to library files as they do to the rest of your data.

If you want written confirmation that a specific file or an entire library has been destroyed, contact us and we will confirm what was deleted and when. Closing your account is handled under the account-deletion process in the Privacy Policy.

Operational limits, so nothing here is a surprise at the moment you need it:

• File size: up to 25 MB per file. Larger uploads are rejected outright.
• File types: PDFs, plain text, Markdown, CSV and log files, and common image formats. Other types may be rejected or may extract no usable text.
• Context limits: the per-file and per-question character limits in section 9 apply when a file is attached to a research question.

And what we ask of you:

• Upload only material you have the right to upload. Do not upload third-party personal data you are not permitted to share with a processor.
• Do not upload material whose use would be unlawful — including, in a securities context, material non-public information you are not entitled to act on.
• Keep your account credentials secure and enable the account protections we offer. Most realistic loss of file confidentiality starts with a compromised account, not with the storage layer.

Security incidents are handled under our Cybersecurity Policy, which sets out detection, containment, investigation and notification. Users affected by a confirmed data breach are notified within 72 hours of confirmed impact, with a description of the incident, the data potentially affected and our recommended actions, in line with that policy and applicable law.

Availability, backup and restoration commitments for the platform as a whole are described in our Business Continuity Policy. If you believe you have found a vulnerability, please report it to us rather than testing it against another user’s data.

We may access, preserve or disclose file contents or metadata where we reasonably believe we are legally required to, or where it is necessary to investigate suspected abuse, protect the rights and safety of users, or enforce our Terms. We assess requests for validity, disclose no more than the request requires, and — where the law permits and no exception applies — notify the affected user.

When we change how library files are handled, we update this document and its version and effective date below. Material changes are announced through the same channels as changes to our Privacy Policy. Prior versions are available on request.

This mapping exists so a reviewer can go criterion by criterion without a call. It follows the AICPA Trust Services Criteria categories that a SOC 2 examination is organised around.