Privacy Policy

Adyrix Systems Private Limited (D No 18-7-96/1, Shivalayam Temple, Kaza, Mangalagiri, Guntur - 522503, Andhra Pradesh, India), the company behind Stemmory.

This policy covers the Stemmory web app and marketing site. It does not cover payment data, which Paddle.com Market Ltd handles as a separate controller under its own privacy policy. See section 5.

1. Who we are

Stemmory is a product of Adyrix Systems Private Limited, an Indian private limited company (CIN: U62090AP2026PTC123598) registered at D No 18-7-96/1, Shivalayam Temple, Kaza, Mangalagiri, Guntur - 522503, Andhra Pradesh, India.

Adyrix Systems Private Limited wears two hats, and it matters which one applies to which data. For your account identity, workspace membership, subscription status and the usage logs described in section 2, we are the controller (GDPR terms) or data fiduciary (DPDP Act terms): we decide how and why that data is processed. For your workspace's content — the feature graph, decisions, ticket data and attribution described in section 2 — your workspace's own organisation is the controller (or data fiduciary), and we act as its processor, handling that content only on its instructions: see section 4.

Contact us at support@stemmory.com. For requests about your personal data specifically, use privacy@stemmory.com, so the right person sees it.

2. What we collect

Account identity. Your email address and login credentials (a password, or a one-time code, depending on how you sign in). Stored in Supabase Auth. We do not currently offer single sign-on.

Workspace content. The material your workspace builds inside Stemmory:

• Frontmatter, a short excerpt (the first paragraph), and decisions parsed from the markdown files in the repository path you configure, which defaults to docs/features, along with each file's path and the identifier (SHA) and date of the commit we read it at, so the graph can say which version of a doc it reflects. We parse these files to build your feature graph. The decisions part is body text, not just metadata, so it deserves a plain statement: for every line in a doc's ## Decisions section written as - YYYY-MM-DD — <title> — because <rationale>, we store that date, that title and that rationale in our database, word for word. If a decision line in your docs contains something sensitive, we are storing it. Beyond that — the title and frontmatter, the excerpt, and those decision lines — we do not store your markdown files, and we do not store anything outside the configured path. We do not store the commit author's name or email.
• Ticket data from Linear: identifiers, titles, status, labels and links for the tickets you connect, so we can derive a feature's status without you typing it in.
• Decisions, feature descriptions and status changes that your team or your coding agents write into Stemmory directly, plus who or what wrote each one and when.
• Integration credentials: the GitHub and Linear access tokens your workspace grants when you connect those tools. These are encrypted before they are stored, with a key that is not kept in the database, so we cannot read them back in plain text either.

Attribution. Every write to your graph records which agent made it (for example, "Claude Code" or "Codex") and, separately, a human handle and device name your agent tooling supplies (for example, "sri" on "macbook-pro"). The agent name is always visible to your workspace. Whether the human handle and device name are shown to your teammates is a workspace-level setting that defaults to off, because in an agency or contractor setting that display becomes performance surveillance. We store the value either way; the setting controls who can see it inside your workspace, not whether we hold it.

Usage logs. We keep an audit log of privileged actions in your workspace: role and membership changes, connection grants, and deletions. Each entry records who did it and when. We do not currently log sign-ins, sign-outs or token refreshes.

3. What we deliberately do NOT collect

Your source code. This is the one we want you to check yourself, not just take our word for. Stemmory stores the documentation it parses from the markdown files in the repository path you configure, the Linear ticket data you connect, and the attribution described in section 2 — not your source code. We do not store or transmit your source code. One caveat, stated plainly because a technical reviewer will spot it anyway: reading any file from a repository, even a markdown file, uses GitHub's contents-read permission, and that permission class is technically capable of reading other files too. So the guarantee we stand behind is about what we store — the configured path's titles, frontmatter, excerpts and ## Decisions lines, as section 2 describes, and nothing outside it — not a claim that the underlying permission is incapable of more. The GitHub App also requires the organisation Members: read permission, which we use for one thing: verifying you are an admin of the GitHub organisation before a connection is allowed (our code refuses the connection without it). The full permission list is shown on GitHub's own screen when you install the App, and in your organisation's installed-app settings afterwards; that screen, not this policy, is the authoritative list, and you can disconnect at any time.

Full payment card or bank details. Paddle.com Market Ltd, our payment provider, runs checkout and billing. We never see your full card number, expiry date or CVV; only Paddle does. See section 5.

Anything from outside your workspace's own connected tools. We do not independently collect data about people who are not members of your workspace. If a Linear ticket or a decision mentions someone by name, that is content your workspace put there, not something we went looking for.

4. Why we process it and the legal basis

We process the data in section 2 to run the service: authenticate you, keep your workspace's data separate from every other workspace, sync from Linear and GitHub, render your graph, and maintain the audit log and security measures described in section 10.

Your workspace's own organisation decides who is a member, what gets recorded, and when data is deleted. It is the controller of that workspace's content; we process it on the workspace's instructions, in the way this policy and our terms describe. For that content, the lawful basis is your organisation's to determine as controller; the table below covers only the data for which we are the controller.

Where a legal basis depends on consent, you can withdraw it by emailing privacy@stemmory.com or by closing your account, subject to the retention points in section 7.

We do not make automated decisions about you that have legal or similarly significant effects, and we do not profile you.

5. Sub-processors and other recipients

We use the following companies to provide the service. Each row states what actually reaches that company, given how Stemmory is built, not a generic description of what the vendor could theoretically see. Not everything here is our sub-processor in the strict sense: GitHub and Linear are your own services, which you connect and can disconnect, and Paddle is an independent controller for payment data. The rows say which is which.

Named here but not yet in use, so you know what's coming rather than being surprised by it later:

• Better Stack, to run a public status page at status.stemmory.com showing whether Supabase and Vercel are up. It would receive no customer data at all, only infrastructure status. We will move it into the table above once the status page is live.
• A transactional email provider, to send sign-in links and one-time codes. We have not finalised which one for production yet. We will name it here, with its region, before it handles any customer's email address.
• Anthropic, for a possible future one-off tool that would read a customer's existing legacy documentation and suggest graph nodes from it, with every suggestion reviewed by a human before anything is saved. This is specified but not built, and nothing is sent to Anthropic today.
• Sentry, for error monitoring, is on our roadmap as optional infrastructure. It is not integrated and processes no data today.

We will update this list, and notify your workspace's owners by email, before any new sub-processor gets access to your data, or before we change hosting region.

6. International transfers

Our database is hosted in India (AWS ap-south-1, Mumbai). We do not currently offer hosting in the EU or EEA.

If you or your organisation are located in the European Economic Area, the UK or Switzerland, using Stemmory means transferring your personal data to India, a country that does not have an EU or UK adequacy decision. A transfer like that needs a legal transfer mechanism. The mechanism we intend to use is the European Commission's Standard Contractual Clauses (the 2021 clauses) and, for transfers from the UK, the UK Addendum to them, incorporated into a data processing agreement with your organisation.

Those clauses are not yet in place with anyone. Our data processing agreement is drafted but has not yet been reviewed by counsel or executed with any customer, and until it is executed with your organisation, no transfer mechanism is in force for your data. For that reason, we ask organisations established in the EEA, the UK or Switzerland not to create a workspace yet. If you want to use Stemmory from those jurisdictions, email privacy@stemmory.com first: we will put the clauses in place with you before you sign up, not after.

If you are subject to India's DPDP Act 2023, your data stays within India, which avoids this question but does not exempt us from the DPDP Act's own obligations, which are separate from and not satisfied merely by GDPR compliance.

7. Retention and deletion

While your account is active, we keep your data to provide the service.

If you delete your own account, we delete your login (your email and credentials) and your workspace memberships. If your workspace's graph contains content you wrote, that content stays: it belongs to the workspace, the same way your work product stays with a company after you leave it. The human handle and device name behind your past writes (section 2, "Attribution") also stay on those writes, for as long as the workspace keeps its graph. If you are the sole owner of a workspace with other members, ownership transfers to another member automatically before your account is erased. If you are the sole member of a workspace, you can choose to delete that workspace along with your account; we ask you to confirm this explicitly first.

The audit log is not deleted by account deletion. It keeps a record of privileged actions, including the user ID, role and dates involved, so a workspace can reconstruct what happened after a security incident even once the person involved is gone. Because the audit log is pseudonymous rather than anonymous, it has a fixed retention period, not an indefinite one: entries are kept while the workspace exists, and for two years after the workspace is deleted, after which they are deleted too. We can delete specific audit entries for a named individual sooner, on your workspace's documented instruction; this is a manual step on our side, not a self-service one yet.

If a workspace is deleted, its graph, decisions, tickets and connections are removed. Its audit history is kept for two years from that deletion, for the reason above, and then deleted.

Your git repository is outside our control. If your team's coding agents write decisions into .stemmory/journal/*.ndjson in your connected repository, that file lives in your own git history, not ours. Deleting data in Stemmory does not remove it from your repository or its history. That is something only you can do, using your own git tooling, the same as any other file you have committed.

Backups. Supabase takes daily backups of our database. On our current hosting plan, backup snapshots are retained for 7 days and then deleted automatically; data you delete can therefore persist in a backup snapshot for up to 7 days, after which it is gone from backups too. That window comes from our hosting plan, so it can change if the plan changes; if it does, we will update this policy. We use backups only for disaster recovery, and we have not yet published a backup restore process.

Data export. A self-service export tool is planned but not yet built. Until it exists, you can request an export of your workspace's data by emailing privacy@stemmory.com; we fulfil this manually, so it is not instant.

8. Your rights

If you are in the European Economic Area, the UK or Switzerland, GDPR gives you the right to access, correct, delete, restrict or object to our processing of your personal data, and the right to receive a copy of it in a portable format. You also have the right to complain to your local data protection authority (in the UK, the Information Commissioner's Office).

If you are in India, the DPDP Act 2023 gives you the right to a summary of what personal data we hold about you and how we process it, the right to have it corrected or erased, the right to nominate another person to exercise your rights on your behalf if you become unable to, and the right to a grievance redressal process with us before you escalate to the Data Protection Board of India. Grievances go to privacy@stemmory.com, where they are handled by Venkata Vamsi Krishna Bhuvanam, our Founder, who is responsible for data protection at Adyrix Systems Private Limited and is able to answer questions about how your personal data is processed. He is the same person named elsewhere on this site as our Grievance Officer under the Consumer Protection (E-Commerce) Rules 2020, where his address is vamsi@stemmory.com; either address reaches him. Those are two roles under two different laws: consumer grievances follow the process published with that role, and data-protection grievances follow this section. We have not appointed a separate Data Protection Officer.

To exercise any of these, email privacy@stemmory.com from the address on your account, telling us what you're asking for. We will verify it is really you before acting on it. Where GDPR or UK GDPR applies, we will respond within one month, extendable by up to two further months for complex or numerous requests, in which case we will tell you within the first month. Where the DPDP Act applies, we will respond within the timelines its rules prescribe.

One thing worth knowing before you ask. If you are a member of a workspace someone else owns, some of the data connected to your account, such as decisions and features you wrote, belongs to that workspace rather than to you personally, for the reasons in section 7. Deleting your own account will not remove that content, and if your organisation needs to answer a request about it, they may need to be the ones to act, not us. If that's your situation, it's worth reading section 7 first.

9. Cookies and local storage

Cookies. We use two, and nothing else:

• A session cookie, which keeps you signed in. It is marked secure and sameSite=lax. It is not marked httpOnly, because Stemmory's live-updating graph needs to read it directly in your browser to keep a realtime connection open; we compensate with the other cookie settings and by never rendering unescaped content into the page.
• A short-lived state cookie, set only for the few seconds you are connecting a GitHub or Linear account, to make sure the connection request came from your own browser and not a forged one. It expires automatically and is not used for anything else.

Neither cookie is used for advertising, cross-site tracking, or building a profile of you.

Local storage. We use your browser's localStorage, not cookies, to remember your light or dark theme preference, and, on the marketing site, which colour palette you're previewing. Both are stored on your own device, are never sent to our servers, and exist purely so the app doesn't flash back to a default on every visit.

Analytics. We do not currently use Google Analytics, PostHog, or any other third-party analytics, advertising or tracking tool on the app or marketing site. If that changes, we will update this section first, and where the law requires it, ask for your consent before anything loads.

10. Security

We describe our security measures in full, with pointers to the actual code and migrations that implement them, in a security document we will share on request: email security@stemmory.com. (Our repository is private, so we do not link it here.) In summary:

• Every table in our database enforces row-level security, so a query can only return rows belonging to the workspace making it. This is enforced by the database itself, not just by application code that could have a bug in it.
• Integration tokens (your GitHub and Linear credentials) are encrypted before they are written to the database, with a key that is never stored in the database. A database backup or a database-console session sees ciphertext, not your tokens.
• We do not use Supabase's service_role key anywhere in our product code. It is banned outright, not merely "used carefully."
• Privileged actions are recorded in an audit log that cannot be read or altered through our normal API.

What we do not yet have, stated plainly rather than left for you to assume: we do not hold a SOC 2 report or an ISO 27001 certification, we have not commissioned an external penetration test, and we do not yet have a Content Security Policy or end-user multi-factor authentication. If you need any of these for a security review, ask us and we will tell you where things stand.

If we suffer a breach involving your personal data, we will notify the authorities within the timescales the law sets: under GDPR and UK GDPR, the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware (where the breach is likely to result in a risk to you), and you directly where that risk is high; under the DPDP Act, the Data Protection Board of India and each affected individual. Where a breach touches a workspace's content, we will also notify that workspace's owners without undue delay so they can meet their own obligations as controller.

To report a security issue, email security@stemmory.com.

11. Children

Stemmory is a business tool for software teams. It is not directed at, and is not intended for use by, anyone under 18. We do not knowingly collect personal data from children. If you believe a child has given us personal data, contact privacy@stemmory.com and we will remove it.

12. Changes to this policy

We may update this policy as the product changes. If we make a material change, we will let you know by email or by a notice inside the app before it takes effect. The date at the top of this page always reflects the version currently in force.

13. Contact

Adyrix Systems Private Limited D No 18-7-96/1, Shivalayam Temple, Kaza, Mangalagiri, Guntur - 522503, Andhra Pradesh, India

• General questions: support@stemmory.com
• Privacy and data rights requests: privacy@stemmory.com
• Security vulnerability reports: security@stemmory.com