Terms of Service

Effective date: [EFFECTIVE DATE] Provider: [LEGAL ENTITY], a company registered in [JURISDICTION], of [REGISTERED ADDRESS] ("we", "us").

These terms govern your use of the superdev service — the hosted API at pando-catalog-api.fly.dev and the credentials we issue for it. By using a key we issue, you agree to them. If you are agreeing on behalf of an organisation, you confirm you may bind it, and "you" means that organisation.

1. What this covers, and what it does not

Covered: the hosted backlog service and the API keys we issue.

Not covered: the superdev plugin, which is separate software distributed under the MIT licence from a public repository. You may use it without agreeing to anything here, including against a backlog you run yourself. Nothing in these terms restricts your rights under that licence, and nothing in that licence entitles you to the hosted service.

The distinction is deliberate. The plugin is a client; these terms are about the service it talks to.

2. The beta, stated plainly

The service is in an invite-only beta. That means all of the following, and you should not enter into any commitment that assumes otherwise:

• It is free, and we may begin charging for future use on notice. We will not invoice you for usage that occurred while it was free.
• There is no service level agreement, no uptime commitment, and no support commitment. It runs on a single machine in one region. Every deployment is a short interruption.
• We may change or withdraw features, including ones you rely on, on reasonable notice.
• We may end the beta, or your access to it, as described in section 9.
• Backups are taken daily and kept for seven days. There is no point-in-time recovery, so up to a day of your data could be lost in a failure, and anything older than seven days cannot be recovered at all. We have rehearsed and documented recovery of the backlog's contents; we have not yet rehearsed our hosting provider's own restore. Do not use this service as the only copy of anything you cannot lose. [REVIEW] — revisit when the physical restore is rehearsed, and again if point-in-time recovery is enabled.

3. Your account and your keys

We issue API keys by hand. Each key carries one role and, normally, one product scope, and the database enforces both.

You must:

• Keep keys secret. A key is printed exactly once and only its hash is stored; we cannot recover one for you and will not try. If a key is exposed, tell us and we will revoke it.
• Not share keys outside your organisation, and not sell, sublicense, or resell access.
• Tell us promptly if you believe a key has been compromised or used without authorisation.

Keys expire — 90 days from issue by default. Expiry is not a suspension; ask and we will issue a replacement.

We may revoke a key immediately, without notice, if we believe it is compromised, or if it is being used in a way that threatens the service or another customer.

4. Acceptable use

You may not:

• Attempt to access another customer's data, or to act outside the scope your key carries.
• Probe, scan, or test the security of the service, or circumvent rate limits, authentication, or any other control. Exception: if you find a vulnerability, we want to hear about it — write to [SECURITY CONTACT], and we will not pursue you for good-faith research reported to us privately and not exploited beyond what is needed to demonstrate it.
• Use the service to store or process anything unlawful, or anything you do not have the right to put there.
• Use it in a way that degrades it for other customers, including automated traffic beyond your rate limit.

We enforce rate limits per key. Exceeding one produces a 429, not a suspension.

5. What you must not put in the backlog

The backlog is designed for product plans: capabilities, features, user stories, acceptance criteria, and the work items that reference them. Do not put the following in it, in any field, including free-text ones:

• Personal data beyond what the service needs. Agent identifiers and key labels are the only places we expect to see anything that identifies a person, and neither needs a real name.
• Special category personal data — health, biometric, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation.
• Payment card data, government identifiers, or health records.
• Credentials of any kind, including your own.

We do not scan for these, so this is a restriction you have to keep rather than one we enforce. Two of the reasons are technical and specific: content is very hard to remove once written (section 6), and free-text backlog fields are not designed to be a place where regulated data lives.

6. Deletion, and its real limits

This section describes what the system can actually do. Read it before you rely on being able to remove something.

The backlog is designed so that a record of a decision outlives the thing it described. In practice:

• Nothing is hard-deleted through the API. Removal is a lifecycle state — a capability, feature, story, or acceptance criterion can be marked removed, and it stops being active, but the row remains.
• Evaluations, evidence signals, and work-item notes cannot be changed or deleted at all, by you or by us, without an operator procedure that disables a database trigger. A wrong record is superseded by a newer one, never edited.

What we can do today, on request:

You ask for	What happens	How long
An export of your data	We produce it and send it to you	[COMMITMENT] business days
Your keys revoked	Immediately, on request	Same day
Your content marked removed	Lifecycle state set; content no longer active or served	[COMMITMENT] business days
Your data erased	A manual operator procedure that does not yet exist	[COMMITMENT] — see below

On erasure specifically, and honestly: the procedure that would erase a customer's data completely is designed but not built. Until it is, an erasure request is satisfied by hand, and we will tell you when it has been done and what was and was not removed. If you need a contractual erasure commitment before then, ask before you sign up rather than after.

[DECISION] — every [COMMITMENT] above, and whether any of them can be promised at all before the purge procedure exists.

7. Your data and ours

You own your backlog content. We claim no rights in it beyond what we need to run the service for you: to store it, to serve it back to you, to back it up, and to fix things when they break.

We may use aggregated, de-identified information about how the service is used — request volumes, error rates, which routes are used — to operate and improve it. Nothing in this category identifies you or discloses your content.

We do not train models on your content, and we do not sell it or share it for advertising.

The Privacy Policy says what is collected. The DPA (not yet published) governs anything in your content that is personal data.

8. Availability, and what we do not promise

We aim to keep the service up and we make no promise that we will. There is no SLA, no credit, and no committed response time during the beta.

The service depends on Fly.io and Supabase (subprocessors list (not yet published)). An outage at either is an outage here, and we cannot commit to a resolution time for something we do not run.

9. Ending it

You may stop using the service at any time, and ask us to revoke your keys.

We may suspend or terminate your access:

• immediately, for a breach of section 4 or 5, or where continued access threatens the service or another customer;
• on [NOTICE PERIOD] notice, for any reason, including ending the beta.

On termination: we will, on request made within [EXPORT WINDOW] days, provide an export of your backlog content. After that window we may remove your access to it. Removal of access is not erasure — see section 6.

10. Warranties, liability, and the parts a lawyer will rewrite

[COUNSEL] — the following are placeholders indicating intent, not drafted language.

• No warranties. The service is provided "as is" and "as available", with all warranties disclaimed to the extent the law allows.
• Liability cap. [CAP]. Note that a fee-based cap is meaningless while the service is free, so this needs a fixed sum or a different mechanism.
• Excluded losses. Indirect, consequential, loss of profit, loss of data — subject to what cannot be excluded in [GOVERNING LAW].
• Indemnity. [COUNSEL] — whether one is appropriate for a free beta at all.

11. Changes to these terms

We may change these terms. For a material change we will give notice to the contact address we hold for you, at least [NOTICE PERIOD] before it takes effect. Continuing to use the service after that is acceptance. If you do not accept, stop using the service and ask us to revoke your keys.

12. General

• Governing law: [GOVERNING LAW]. Venue: [VENUE].
• Entire agreement: these terms, the Privacy Policy, and any DPA we sign with you.
• Assignment: you may not assign without our consent; we may assign to a successor of our business.
• Severability: if a provision is unenforceable, the rest stands.
• Contact: [PRIVACY CONTACT].