Legal
Privacy Policy
This is the full text of the current Privacy Policy. New acceptances are recorded against these exact bytes by their SHA-256. If you accepted an earlier version, your record stays pinned to the version you were shown. You can request that version from support@graunt.com.
sha256:2cff8eebe2718aed172c5b04d4c0a57512f03ddf3e469634ef5e4be24efdd3a5
# Graunt — Privacy Policy
**Version:** 1.11 | **Effective:** October 21, 2026 | **Status:** Operational terms. **Governs:** Graunt's collection, use, disclosure, and retention of personal information about the people who use Graunt (account holders, the people who act for them, and visitors) and about the people Graunt invites to sell on Graunt. Does **not** govern content uploaded by sellers for sale, except as described in §3.6 — that content is governed by the Acceptable Use Policy and the Marketplace License.
---
## 1. Who we are
This policy describes how Graunt, Inc., a Delaware corporation ("Graunt," "we," "us") collects, uses, and discloses personal information when you use the Graunt marketplace (the "Service") at graunt.com and via its associated APIs.
**Contact:** support@graunt.com (subject line "Privacy")
## 2. Scope
This policy applies to:
- **Platform users:** individuals who open an account (for themselves or for an organization), access the Service, or act on behalf of an account holder.
- **Communications with the Service:** emails, webhooks, support requests, and API traffic originating from platform users.
- **People we invite to sell:** individuals who publish data and whom we contact about listing it on Graunt (§3.4).
This policy does **not** apply to:
- The content sellers upload for sale on the marketplace. That content is governed by the Marketplace License (graunt.com/legal/marketplace-license) and the Acceptable Use Policy (graunt.com/legal/aup). Sellers are responsible for obtaining any consents, performing any notices, and otherwise ensuring lawful collection and distribution of the content they list. The platform is not the data controller of seller-uploaded content for sale.
- Third-party sites linked from the Service. We are not responsible for the privacy practices of third parties.
## 3. Information we collect
**Information you provide directly:**
- **Account data.** Your name, your email address, your password (stored only as a salted hash), whether you hold the account as an individual or for an organization, and the organization's name where there is one. Your email address is stored encrypted.
- **Identity / credential data.** When you submit identity verification or professional credentials, we collect the information and documents you provide.
- **Financial onboarding data.** When you connect a Stripe Connect account for payouts, Stripe collects the information required under its own terms; we receive only the references and status information Stripe returns to us.
- **Content you create on the platform.** Listings, listing metadata, files you upload to prepare a packet, seller guide responses, access-request messages, support-ticket content.
- **Communications.** When you contact us by email, through support, or through the rights-review form on a listing, we retain those communications.
- **Connected assistants and agents.** When you connect an AI assistant to your account, we keep a record of the connection: the assistant's name, what it may access, and when it was created and last used. When you create an agent, we keep its name, its stated purpose, its credentials (stored as hashes), and a record of what it does in your account.
**Information collected automatically:**
- **Authentication data.** Session tokens (carried in a sign-in cookie, §3.5), API keys and access passes (stored only as hashes), password hashes, email verification tokens.
- **Usage logs.** IP address, user-agent, request path and method, response status, timestamp, request ID. Used for security, rate limiting, and operational diagnostics.
- **Pages you view.** When a page of the Service loads in your browser, it reports the page's path and the kind of page, together with the identifier from the first-party cookie described in §3.1. We use these records to count visits and to see which pages people use.
- **Agent and API activity.** For each call to our MCP connector, and for requests to certain machine-readable routes, we record which tool or route was called and whether it worked. These records are counted without your account; what an agent buys, lists or accepts for you is recorded on your account, as yours.
- **Audit log events.** Security, commerce, rights and account actions are written to an append-only audit log. Audit events are scoped to accounts and do not include content PII.
- **Traffic-source (attribution) data.** On your first visit we set a first-party cookie containing a randomly generated identifier, and we keep one record per identifier. Section 3.1 describes this in full.
- **Derived approximate location.** We derive a coarse location label (country; state for United States registrations) from your IP address at the time of a request. Section 3.2 describes this in full, including the boundary that matters: the derivation happens locally on our own servers, and your IP address is not sent to any geolocation provider.
**Information we receive from others:**
- **Payment events.** Stripe sends us webhook events about payment status, chargebacks, and transfer outcomes. We receive transaction metadata, and the billing address Stripe collects at checkout where we need it to work out sales tax, but not the full card number or bank account details.
- **Email delivery events.** Our transactional email provider (AWS SES) reports bounces, complaints, and deliveries back to us.
- **Public sources.** For the people we invite to sell, the public pages described in §3.4.
### 3.1 Traffic-source (attribution) data
We measure which channels bring people to the marketplace. This measurement is first-party: it runs on our own systems, and the data does not go to an advertising network or a third-party analytics vendor.
**What the record contains:**
- The randomly generated identifier from the first-party cookie.
- The campaign parameters present in the link you followed — `utm_source`, `utm_medium`, `utm_campaign`, `utm_term`, and `utm_content` — captured from your **first** visit only and not overwritten by later visits.
- The host and path of the site that referred you, also from your first visit only.
- Whether the link carried an advertising click identifier, and which advertising network it belonged to. We record that one was **present**; we do not store its value.
- A coarse classification of the client software you used (for example, a browser or an automated agent acting on your behalf).
- When you first arrived and when you were last active.
**What the record does not contain.** No name, no email address, **no IP address**, and **no browser user-agent string**. These are not merely withheld from reports — they are not written to the record.
**Automated crawlers are excluded.** Requests we identify as search-engine indexers, AI training crawlers, or other recognized bots receive no cookie and produce no attribution record. Crawler volume is counted separately as an aggregate operational statistic and is never attributed to a traffic source. This exclusion changes only what we record; it never changes what a crawler is served.
**Linkage to your account.** If you go on to open an account, verify your email address, sign in, publish a listing, redeem an access code, or complete a purchase, we record that event against the same identifier, together with your account identifiers and the transaction amount. This is how a purchase is connected back to the channel it came from. Once that linkage exists, the record — and the page-view records carrying the same identifier — are personal information, and every right in §8 applies to them.
**Your choices.** Clearing cookies in your browser ends the link between your later visits and the earlier record. You may also request deletion of these records under §8.
**No advertising use.** We do not use this data to build advertising profiles, to target advertising to you, or to enrich it with data purchased from third parties.
### 3.2 Derived approximate location
We derive an approximate location from your IP address at the time of a request, so we can understand where marketplace usage and signups come from.
**How the derivation works.** The lookup runs locally, on our own servers, against a geolocation dataset stored there. **We do not send your IP address to any geolocation provider or other third party to obtain a location; approximate location is derived locally.** The dataset is a fixed, versioned snapshot, and every derived label is stored together with an identifier of the dataset version that produced it. The result is an estimate of where the network address appears to be — not a statement of anyone's residence, nationality, or physical location — and it can be wrong: mobile carriers, corporate networks, and VPNs routinely place traffic far from the person using them.
**What we derive and where it is stored:**
- **Usage measurement.** Usage analytics events may carry a country label (for example, "US"). Country is the only location granularity recorded on usage events — no state, no city.
- **Registration signup origin.** The account record carries the country — and, for registrations from the United States, the state or territory — derived once at registration and stored at that moment. It is not recomputed later, and accounts registered before this practice began carry no derived origin. If the account is deactivated or its registration identity is released, the derived origin is removed from the account record at that transition.
**What we do not derive or store.** We do not retain, display, or log city, postal-code, or coordinate lookup results about a request or an account — the dataset on our servers contains that finer detail, and we copy only the country and, for United States registrations, an approximate state or territory code into our records. The derived label is stored instead of, never alongside, the IP address on usage analytics events; the underlying IP handling described under "Usage logs" in §3 is unchanged. Location labels are not added to the traffic-source record described in §3.1. Where the dataset cannot place an address, nothing is recorded.
**Where it appears.** Derived location is used in our own operator views in aggregate (with small counts grouped together) and on internal account administration records. It is never shown on public marketplace surfaces, and no automated system reads it — nothing prices, ranks, gates, or rate-limits by it. In a manual fraud or abuse review, our operator may see the label as context beside the account's other records; it is never the sole basis for an adverse action against an account.
### 3.3 Legal acceptance records
When you accept one of our legal documents, we write a record of that acceptance and keep it as evidence of the agreement. The moments we record are: the Terms of Service, this Privacy Policy, the Acceptable Use Policy and the electronic-records consent when you open an account; the Seller Agreement and the seller rights attestation before your first listing; the Acceptable Use Policy again when you create a listing; the Buyer Terms when you pay, and the Held Purchase Authorization at a held authorization; a seller's additional terms at checkout, where a listing carries them; the Referral & Commission Terms when you create a referral link; the Contributor Earnings Terms before a contributor payment; and the rights attestation a discovery-key holder makes before submitting a draft.
**What the record contains:**
- The account that accepted, and the user who acted where a signed-in user was involved.
- Which document was accepted, at which version, together with a cryptographic hash of that document's exact text. The hash is what makes the record precise: it identifies the exact wording that was agreed to, rather than naming a document that may since have been revised.
- When the acceptance happened, and which part of the Service it happened in.
- The IP address and browser user-agent string present at that moment, as evidence of where and how the acceptance was made. These are stored in full, not hashed. This is a separate, durable record — not the rolling usage log described above, and not kept for the same period.
- When an agent accepted for you, which agent it was, the sentence Graunt served to it, and the digest of the terms it was served.
**Why we keep it.** If a question arises about whether an account agreed to a particular version of our terms, this record is the answer. That is its only job.
**Where it appears, and where it does not.** Acceptance records are visible to our operator on internal account administration records. They are never shown on public marketplace surfaces, never sent to an advertising network or a third-party analytics vendor, and never used for advertising, ranking, or pricing.
**How long it is kept.** The acceptance itself — account, document, version, hash, and time — is kept for the life of the account record. The IP address and user-agent on it are kept for the life of the account's registration identity, and are cleared when that identity is released; a registration that never verifies its email address and is later retired is the case that happens in practice. Section 6 states this in the retention table, and every right in §8 applies to these records.
### 3.4 People we invite to sell
Graunt invites people who publish datasets to sell them on Graunt. We find them through public dataset pages (for example a dataset card on Hugging Face) and the publisher's own website. We write to a person only at an email address printed on their own website, and only when that site shows they are in the United States.
For each person we keep their name, that address, the public pages the address and the person's location came from, what we sent and when, and their replies. Replies are sorted automatically (§10), so a request to stop is honored even before anyone has read it. Every message says how to opt out. When you opt out, we delete your address from our records and keep only a one-way fingerprint of it, so that we never write to you again. You can also ask us to delete everything we hold about you (§8).
### 3.5 Cookies
The Service sets these first-party cookies, and no third-party advertising or analytics cookies:
- **Sign-in cookie.** Keeps you signed in. It holds your session token and expires with your session.
- **Signed-in hint.** Records only that this browser has signed in, so pages can show the right navigation before they load your account. It holds no identifier.
- **Traffic-source cookie.** Holds the random identifier described in §3.1. It expires after 90 days.
- **Graunt staff marker.** Set only on browsers used by Graunt's own staff, so our own visits are left out of our counts.
### 3.6 Files you scrub before listing
When you upload a file to Graunt's personal-details step, Graunt reads it only to remove the personal details you choose (your own names, addresses, email addresses and phone numbers, and the columns that identify people) and to check what is left before you list it. The original file is kept in a private area that nothing else reads. Every stored copy of it is deleted when you confirm or leave the step, and anything left behind is deleted within 24 hours. Graunt keeps the scrubbed file, which becomes your packet's source, and a record of what was removed and kept, never the removed values. Graunt does not attempt to re-identify any person in a scrubbed file, and its terms forbid anyone else from trying.
## 4. How we use your information
We use the information we collect to:
1. **Operate the Service.** Authenticate users, authorize actions, enforce access policies, deliver entitlements, process payments and payouts.
2. **Communicate with you.** Send verification emails, transactional notifications (listing status, purchase receipts, payout notices), notices of changes to the terms that govern your account, and security alerts.
3. **Enforce our policies.** Investigate abuse, enforce the AUP, process DMCA notices, administer the Repeat Infringer Policy, respond to law-enforcement requests.
4. **Keep the Service secure.** Detect and respond to fraud, abuse, intrusion attempts, and availability threats.
5. **Comply with law.** Satisfy tax, audit, regulatory, and legal-process obligations.
6. **Improve the Service.** Analyze operational metrics; aggregated, de-identified usage statistics.
7. **Measure how people find and use the marketplace.** Use the traffic-source data described in §3.1, and the page-view records in §3, to understand which channels bring visitors, which pages they use, and which of those visits lead to registrations and purchases. Unlike item 6, this data is not aggregated or de-identified — it is a per-visitor record, and once linked to an account it is personal information.
8. **Understand where usage and signups come from.** Use the derived approximate location described in §3.2 — country-level usage measurement, and registration-time signup origin on the account record — for operational understanding, security and fraud defense, and tax and compliance planning. The signup origin on an account record is personal information and every right in §8 applies to it.
9. **Prove what was agreed.** Keep the legal acceptance records described in §3.3 as evidence of which version of which document an account accepted, and when — for contract, compliance, and dispute purposes.
10. **Tell you about the marketplace.** Send occasional announcements to the email address on a registered account — for example, that a capability an account was waiting on is available, or that the marketplace has changed in a way that affects how an account uses it. This is a use of your registration email beyond the verification, transactional and security messages in item 2. Three limits apply and each is enforced, not merely stated:
- **Registered accounts only.** These messages go to email addresses that opened an account with Graunt and verified that address. We do not send them to addresses obtained from any other source, we do not buy or rent lists, and we do not send them to people who have not registered.
- **Opt out at any time, from any message.** Every such message carries a working unsubscribe link and a one-click unsubscribe header. Opting out suppresses these announcements only; it does not stop the verification, transactional and security messages in item 2, because those carry the receipts, entitlements and account-security notices you need in order to use an account you still hold.
- **Never a condition of service.** Opting out does not degrade the Service, change pricing, or affect any listing, entitlement, purchase or payout.
11. **Invite people to sell.** Write to the people described in §3.4 about listing their data on Graunt. This is the one kind of message we send to people who have not opened an account, and §3.4 sets out its limits.
We do **not** use platform-user information to train machine learning models. We do **not** sell platform-user information. (Note: this policy is about users' personal information; content that sellers voluntarily list for sale is a different thing, governed by the Marketplace License.)
## 5. How we disclose your information
We disclose personal information only as described below:
- **Subprocessors.** We use third-party service providers to operate the Service. Our current subprocessors are listed in §10. Subprocessors are contractually bound to confidentiality and to use personal information only to perform services for us.
- **Payment partners.** Stripe receives the information necessary to process payments, payouts, and disputes under its own terms of service and privacy policy.
- **Counterparties to a transaction.** When you buy a listing, its seller sees that a sale was made and its amount; we do not give the seller your name or email address. A seller's name appears on its listings and on its public seller page.
- **Legal process.** We disclose information in response to valid legal process (subpoenas, court orders, search warrants) as required by law. Where permitted, we notify the affected user before disclosure.
- **Trust & Safety.** We share information across the platform's Trust & Safety, legal, and security functions as necessary to enforce our policies.
- **Business transfers.** In a merger, acquisition, financing, reorganization, bankruptcy, or sale of all or part of our assets, personal information may be transferred subject to the protections of this policy. We will notify affected users of material changes.
We do not sell personal information as that term is defined under the California Consumer Privacy Act (CCPA), the California Privacy Rights Act (CPRA), or any analogous state law.
The traffic-source data described in §3.1 and the page-view records in §3 are not disclosed to anyone outside the categories above. They are not transmitted to an advertising network, an ad-measurement partner, or a third-party analytics provider, and no third-party analytics or advertising tag is served from the marketplace. The derived location labels described in §3.2 likewise reach no third party: the derivation itself is local, and the stored labels stay within the Service.
## 6. Retention
We retain personal information for the following periods:
| Category | Retention |
|---|---|
| Account record | Indefinite while active; purged on request per §8 subject to legal-hold exceptions |
| Purchase records and entitlements | 7 years |
| Audit log events | 7 years |
| Legal notices (DMCA, takedown) | 7 years |
| Listings and datasets | Indefinite while active; retired on seller request or takedown |
| Raw operational logs (request logs, etc.) | 90 days rolling, absent a legal hold |
| Page-view and agent-activity records (§3) | 180 days |
| Traffic-source visit records (§3.1) | 365 days from last activity; the window rolls forward each time the visitor returns |
| Traffic-source conversion records (§3.1) | 730 days, aligning with the accounting and dispute-resolution period for the transaction described |
| Derived country labels on usage analytics events (§3.2) | Stored inside the analytics event row and purged with it under the analytics retention window |
| Legal acceptance records (§3.3) | The acceptance itself — account, document, version, text hash, time — for the life of the account record. The IP address and user-agent on that record: for the life of the account's registration identity, cleared when that identity is released. Removed on request per §8 |
| Registration signup origin on the account record (§3.2) | Life of the open account: removed when the account is deactivated or its registration identity is released (the deactivated account row may persist as an inert tombstone; the derived origin does not), and removed on request per §8 |
| Connected-assistant and agent records (§3) | Life of the account record |
| Records of people we invite to sell (§3.4) | Until the person opts out or asks us to delete them; after an opt-out we keep only the one-way fingerprint of the address, for as long as the opt-out applies |
| Original files uploaded to the personal-details step (§3.6) | Deleted when you confirm or leave the step; anything left behind within 24 hours |
| Announcement opt-out and suppression records (§4 item 10) | Kept for as long as the address is suppressed, and not deleted on an account-deletion request. An opt-out is a standing instruction not to email you; deleting the record of it would cause the very contact you asked us to stop. This is the one category §8 deletion does not clear, and it holds only the address, the suppression reason and the time |
| Announcement delivery events (bounces, complaints, deliveries) | 90 days rolling, on the same basis as raw operational logs |
## 7. Security
We use industry-standard technical and organizational measures to protect personal information, including:
- Encryption in transit (TLS) for all API and web traffic.
- Encryption at rest (AWS S3 SSE-S3) for stored content, and encryption of stored email addresses.
- Short-lived presigned URLs (≤ 15 minutes) for file delivery, never logged.
- Salted hashing of passwords, and hashing of API keys and access passes, so the raw secrets are never stored.
- Append-only audit log for security, commerce, rights and account actions.
- Automatic rotation of database credentials.
- Scoped database access (every query is scoped to the account it serves).
No security measure is perfect. You are responsible for protecting your account credentials and for promptly reporting suspected unauthorized access.
## 8. Your rights
Depending on where you reside, you may have rights to:
- **Access** the personal information we hold about you.
- **Correct** inaccuracies in that information.
- **Delete** your personal information, subject to legal and contractual exceptions.
- **Port** your information to another service.
- **Opt out** of specific processing activities.
- **Non-discrimination** for exercising these rights.
These rights apply equally if you are someone we invited to sell (§3.4) and have no account.
**Announcements are opted out without a request.** You do not need to email us to stop the marketplace announcements described in §4 item 10 — every one of those messages carries an unsubscribe link and a one-click unsubscribe header, and using either is immediate and final. One narrow exception to the deletion right follows from it: we keep the suppression record itself (address, reason, time) for as long as the address is suppressed, and a deletion request does not clear it, because deleting the record of an opt-out would resume the contact you asked us to stop. §6 states this in the retention table.
To exercise any of these rights, email support@graunt.com with the subject line "Privacy request." We will respond within the timeframes required by the applicable law (typically 45 days under the CCPA). Requests are processed by our team through the support channel; we may need to verify your identity before acting on a request.
Residents of California, Colorado, Connecticut, Delaware, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nevada, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah, and Virginia have specific rights under state comprehensive privacy laws. Residents of the European Economic Area, the United Kingdom, and Switzerland have rights under the General Data Protection Regulation and analogous laws. Contact us to exercise those rights.
## 9. International transfers
Graunt operates from the United States, and the Service is offered to users in the United States. If you access the Service from outside the United States, your personal information will be transferred to, processed in, and stored in the United States, and you acknowledge that U.S. law may provide different protections than the law of your jurisdiction.
## 10. Subprocessors
We currently use the following subprocessors to operate the Service. This list is maintained as of the version date below and may change; material changes are announced on this page with 30 days' notice.
| Subprocessor | Purpose | Data involved |
|---|---|---|
| Amazon Web Services, Inc. | Hosting (compute, database, cache), storage (S3), transactional email delivery (SES) | All platform data, content, and communications |
| Stripe, Inc. | Payment processing, payouts (Stripe Connect), tax calculation and reporting | Payment-related identifiers, amounts, and the billing address used for tax |
| Functional Software, Inc. (Sentry) | Error monitoring and diagnostics | Redacted error reports; secrets, tokens, and personal identifiers are scrubbed before transmission |
| Zoho Corporation | Business email: Graunt's mailboxes, including support@graunt.com and the mailbox that sends invitations to sell | Messages you send us and our replies; the names and addresses of the people we invite to sell, and their replies |
| Anthropic, PBC | Packet processing when a seller runs the Refinery on their own upload; sorting replies to our invitations to sell (§3.4) | Seller-submitted content being prepared for listing, which is not platform-account personal information; and the text of a reply someone sends to an invitation to sell |
| OpenAI, L.P. | Packet processing when a seller runs the Refinery on their own upload, including speech-to-text | Seller-submitted content being prepared for listing, which is not platform-account personal information. For speech-to-text, OpenAI receives the audio of a seller's recordings, including the sound track of seller video, and returns the words spoken with their times |
| SpaceXAI LLC (xAI) | Packet processing when a seller runs the Refinery on their own upload | Seller-submitted content being prepared for listing, which is not platform-account personal information |
## 11. Children
The Service is not directed to children under 13, and we do not knowingly collect personal information from children under 13. If you believe we have collected such information, contact support@graunt.com and we will delete it.
## 12. Changes to this policy
We may update this policy from time to time. Material changes will be announced on this page with **30 days' notice** before taking effect. Non-material changes (typo fixes, contact updates, subprocessor list refresh) may be made without advance notice, with the version history reflecting the change.
Continued use of the Service after a change takes effect constitutes acceptance of the updated policy. If you do not accept a change, your remedy is to stop using the Service and request deletion of your account under §8.
---
## Version History
| Version | Date | Changes |
|---------|------|---------|
| 1.11 | October 21, 2026 | §10 now says OpenAI receives the audio of a seller's recordings for speech-to-text, where it had said Graunt ran none and sent none. Speech-to-text turns the speech in a seller's audio and video into time-stamped passages a buyer can cite; it runs when a seller prepares their own upload, as the rest of the Refinery does. OpenAI has been listed for Refinery processing since 1.4, which named the speech inside a seller's upload as a category it receives once speech-to-text runs, so this is **no new subprocessor and no new category of information**: it applies to content submitted for listing, never to platform-account personal information. Acceptances recorded against 1.10 remain pinned to the 1.10 text and its hash. |
| 1.10 | October 21, 2026 | Adds §3.6 and a retention row for the personal-details step: the original file is deleted when the seller confirms or leaves the step, and anything left behind within 24 hours; Graunt does not attempt to re-identify any person in a scrubbed file. The opening scope line notes §3.6 as the one place this policy covers content uploaded for sale. The step is new and seller-initiated, and it narrows what Graunt keeps; no existing processing changed. Founder determination 2026-10-20: non-material, effective on publication, so an acknowledgment of 1.9, 1.8 or 1.7 still holds. Acceptances recorded against 1.9 remain pinned to the 1.9 text and its hash. |
| 1.9 | October 20, 2026 | Subprocessor list refresh: SpaceXAI LLC (xAI), the entity named in xAI's own terms for its API, added for packet processing when a seller runs the Refinery on their own upload, with the same purpose and the same data as Anthropic and OpenAI: seller-submitted content being prepared for listing, which is not platform-account personal information. §12 treats a subprocessor list refresh as non-material, so this version takes effect on publication and an acknowledgment of 1.8 or 1.7 still holds. No other processing described in this policy changed. |
| 1.8 | October 20, 2026 | The policy now describes practices it had left out, and speaks of one account that buys and sells. **No new collection and no new processing** — each addition describes something the Service already does. Added to §3: page-view records tied to the traffic-source identifier, agent and API activity, and connected assistants and agents; the payment and delivery events moved under a new "Information we receive from others" heading. §3.3 now lists every acceptance moment the Service records (it had named a publisher onboarding that does not exist and omitted the seller gate, the referral and contributor terms, held authorizations and agent acceptances). New §3.4 describes how Graunt finds and writes to people it invites to sell, and §3.5 lists the cookies the Service sets. §4 adds item 11 and item 7's page views; §5 corrects what a seller sees about a buyer (the sale and its amount, never the buyer's name or address) and removes a confidential-seller arrangement that is not offered; §6 adds three retention rows; §3 and §7 describe the audit log as it is written (security, commerce, rights and account actions, not every action), and §7 states only security measures Graunt can show; §8 extends the rights to people invited to sell. §10 adds Zoho Corporation (Graunt's email provider, used throughout) and Anthropic's reply sorting, keeps the statement that Graunt runs no speech-to-text and sends no speech, and drops the sentence about what would follow if it did. Account wording replaces organization wording throughout. Acceptances recorded against 1.7 remain pinned to the 1.7 text and its hash. |
| 1.7 | October 6, 2026 | Added §4 item 10 (marketplace announcements to registered accounts), two retention rows in §6, and the opt-out carve-out in §8. This is a **new use of an email address already collected** — no new collection, no new subprocessor, no new disclosure — and it is therefore a **material change**, published with the 30 days' notice §12 requires: adopted September 6, 2026, effective October 6, 2026. **No announcement may be sent before the effective date.** The audience is limited to registered accounts that verified their address; opting out is available in every message and suppresses announcements only, never the transactional and security messages in §4 item 2. The suppression record itself is deliberately excluded from §8 deletion, because deleting the record of an opt-out would resume the contact the opt-out asked us to stop. |
| 1.6 | August 28, 2026 | Internal identifiers removed from the published text: references naming Graunt's own decision and planning records, which identified nothing a reader could consult. Editing was confined to removing those references and, where one was a sentence's only subject, stating in plain words what the sentence described. Acceptances recorded against 1.5 remain pinned to the 1.5 text and its hash. |
| 1.5 | August 17, 2026 | Added §3.3 (legal acceptance records), a corresponding use in §4, and a retention row in §6. This discloses a record this document has always been silent about: when you accept a legal document, the acceptance is stored with the IP address and browser user-agent present at that moment. §3's "Usage logs" bullet describes the rolling operational log; the acceptance record is a separate, durable write with a different purpose and a longer life, and naming only the former left the latter undescribed. **No new collection and no new processing** — the practice dates to the platform's first release; this is the document catching up to it. In the same release the retention of that provenance **narrows**: it is now cleared when an account's registration identity is released, by the sweep that retires never-verified registrations. This version also repairs a character-encoding corruption introduced into the 1.4 text by an unrelated release, in which every em-dash, section sign, and curly quote was double-encoded; the wording of 1.4 is unchanged by that repair. |
| 1.4 | August 17, 2026 | Subprocessor list refresh: OpenAI, L.P. added for seller-initiated Refinery processing. Audio and video also became accepted packet source material, so where speech-to-text forms part of a packet the speech inside a seller's upload is a data category this subprocessor receives. Graunt does not run speech-to-text on seller audio or video, and sends none to this subprocessor — a packet whose text is itself a transcript is not Graunt processing speech. The row is published ahead of any such processing, so the disclosure never trails the practice. Refinery processing remains seller-initiated and applies to content submitted for listing, never to platform-account personal information. No other processing described in this policy changed. |
| 1.3 | August 17, 2026 | Retention criterion for the registration signup origin stated precisely (§3.2, §6): the derived origin is removed when the account is deactivated or its registration identity is released, rather than being retained for the life of the stored account row. This **narrows** retention — no new data is collected and no new processing is introduced — and the removal is enforced structurally by a database constraint rather than by a scheduled job. |
| 1.2 | August 17, 2026 | Added §3.2 (derived approximate location), a corresponding use in §4, a non-disclosure sentence in §5, and two retention rows in §6. This is an **additive disclosure published no later than the practice it describes**, so no location label predates the disclosure. There is no backfill — accounts registered and events recorded before activation carry no derived location. The derivation is local; IP addresses are not sent to any geolocation provider. No other processing described in this policy changed. |
| 1.1 | August 9, 2026 | Added §3.1 (traffic-source / attribution data), a corresponding use in §4, a non-disclosure statement in §5, and two retention rows in §6. This is an **additive disclosure**: it describes a practice that became active on August 9, 2026 and was published on the public privacy page at graunt.com/legal/privacy on that date, and it brings this document into line with that page. There is no backfill — no traffic-source data predating activation exists. No other processing described in this policy changed. |
| 1.0 | July 8, 2026 | Finalized for launch (founder-approved). Entity named (Graunt, Inc., Delaware); subprocessor list audited against production (AWS, Stripe, Sentry, Anthropic for seller-initiated Refinery processing); privacy-request channel set to support@graunt.com; international-transfer statement aligned with U.S.-only service posture; internal references removed. |
| 0.1 | April 2026 | Initial version. Establishes scope boundary (user PII vs seller-uploaded content for sale), retention table aligned with Graunt's data-lifecycle policy, state-law rights references, subprocessor audit placeholder. |