Trust centre: printable pack

Terms of Service

Version 0.1.0 · effective: DRAFT

In one line: The rules for using qypu. You own your content and sign every post; we run the service with care and tell you before we change these terms.

The short version

• These terms are a contract between your business and [ENTITY NAME]. You must use qypu for business, not as a consumer. (Full text, sections 1 and 2)
• qypu is a set of AI engines. Each engine drafts work for you. A named person in your business signs it before anything goes out. (Sections 3 and 6)
• You own your content and your brand. You give us permission to use it only to provide the service. (Section 7)
• We do not use your content to train AI models, and our AI providers may not either. (Section 7.4)
• You must follow the Acceptable Use Policy and the Content Policy. Political content is not allowed. (Section 5)
• You pay the fees shown when you sign up. You can cancel at any time; the rules on refunds are in Billing basics. (Section 9)
• AI can be wrong. You are responsible for what you sign. We limit our liability, but not where the law forbids it. (Sections 11 and 12)
• We will give you at least 30 days' notice of material changes to these terms. (Section 15)

Full text

1. Who we are and who these terms cover

1.1 These Terms of Service ("Terms") are an agreement between [ENTITY NAME], of [REGISTERED ADDRESS] ("we", "us", or "qypu"), and the business that creates a workspace ("Customer" or "you").

1.2 The person who accepts these Terms confirms they are authorised to bind the Customer.

1.3 If you have signed a separate written agreement with us, including the qypu Standard Agreement, that agreement wins where it conflicts with these Terms.

2. Business use only

2.1 qypu is for businesses, sole traders, and other organisations acting in the course of business. It is not for personal, family, or household use.

2.2 Users must be at least 18 years old.

2.3 If the law where you are treats you as a consumer despite clause 2.1, you keep every right that law gives you. Nothing in these Terms removes those rights.

3. The service

3.1 qypu provides AI "engines" that help small businesses with front-office, middle-office, and back-office work. The first engines are SOE Studio (social content) and AVM (valuation estimates). Each engine is described on its product page and in its engine-specific annex.

3.2 We may improve, change, or retire features. If a change materially reduces a feature you pay for, we will tell you at least 30 days in advance, and you may cancel and receive a pro-rata refund of prepaid fees for the unused period.

3.3 Features labelled "Planned" or "Beta" are not part of the service commitment until we label them "In place".

4. Your workspace and your users

4.1 You control who can use your workspace ("Authorised Users"). You are responsible for their actions in qypu.

4.2 Keep sign-in details secure. Tell us at [CONTACT EMAIL] without delay if you suspect misuse.

4.3 You must give your staff any notice the law requires before they use qypu, including any notice about workplace monitoring where an engine observes work.

5. Rules of use

5.1 You must follow the Acceptable Use Policy, the Content and Political Content Policy, and the platform rules of every channel you connect.

5.2 We may pause a post, a channel, or a workspace if we reasonably believe it breaks those rules or the law, or puts people or our service at risk. We will tell you why, unless the law or a safety risk prevents it, and you may appeal under the Complaints and Contact page.

6. Human sign-off and editorial responsibility

6.1 Nothing is published or sent on your behalf until an Authorised User you have named signs it. Any change after signing needs a new signature.

6.2 You hold editorial responsibility for everything you sign. We provide drafts, checks, and tools; we do not decide what you publish.

6.3 Our checks (for example, brand fact checks and policy checks) reduce risk. They do not guarantee that content is accurate, lawful, or suitable.

7. Your content and your data

7.1 You own the content, brand assets, facts, and data you give us ("Customer Content") and the outputs we generate for you, to the extent the law allows anyone to own them.

7.2 You grant us a non-exclusive, worldwide, royalty-free licence to host, copy, process, adapt, and transmit Customer Content only to provide, secure, and support the service for you, and as the law requires.

7.3 Where we process personal data for you, the Data Processing Addendum applies and forms part of these Terms.

7.4 We do not use Customer Content to train or fine-tune AI models, and our contracts with AI providers prohibit them from doing so. We may use aggregated, de-identified service statistics (for example, average approval time) to run and improve qypu; these cannot identify you or any person.

7.5 You promise that you have the rights you need in Customer Content, including consent from any person who appears in it or whose voice or likeness you ask us to use.

8. Connected accounts

8.1 When you connect a channel, you authorise us to act for you within the permissions you grant. The Account Connection and Authorisation Policy explains how this works and how to revoke it.

8.2 Platforms may change or withdraw their interfaces. We are not responsible for a platform's decisions, but we will tell you promptly when a change affects you.

9. Fees, billing, and cancellation

9.1 You pay the fees shown in your plan or order. Fees exclude taxes unless stated.

9.2 Subscriptions renew each period until cancelled. You may cancel at any time in Settings; cancellation takes effect at the end of the current period, unless Billing basics says otherwise.

9.3 If an engine uses outcome-based pricing, the method, baseline, and share are set out in your order before work starts.

9.4 If you do not pay an undisputed invoice within 14 days of a reminder, we may suspend the service after a further 7 days' notice.

10. Our responsibilities

10.1 We will provide the service with reasonable skill and care, protect Customer Content as described in the Security Overview, and use only the subprocessors listed on our Subprocessors page.

10.2 We aim to meet the targets in the Service Levels page. Those targets are not guarantees unless your order says so.

11. Disclaimers

11.1 AI outputs can be incomplete, inaccurate, or unsuitable. You must review outputs before you rely on them, publish them, or act on them.

11.2 Valuation estimates from the AVM engine are not professional appraisals. The Valuation (AVM) Disclaimer applies.

11.3 Except as stated in these Terms, and to the extent the law allows, the service is provided without further express or implied warranties.

12. Liability

12.1 Nothing in these Terms limits liability that cannot be limited by law, including liability for death or personal injury caused by negligence, fraud, or wilful misconduct.

12.2 Subject to 12.1, neither party is liable for indirect or consequential loss, or for loss of profit, revenue, or goodwill.

12.3 Subject to 12.1, each party's total liability under these Terms in any 12-month period is limited to the greater of the fees you paid in that period and [LIABILITY FLOOR, e.g. US$1,000 / £1,000 / €1,000].

12.4 The caps in 12.3 do not apply to your payment obligations or to either party's breach of the confidentiality or data protection obligations, which are capped at [DATA BREACH CAP, e.g. 3 x fees in the prior 12 months].

13. Indemnities

13.1 You will defend and compensate us for third-party claims arising from content you signed, rights you did not have under 7.5, or your breach of the Acceptable Use or Content policies.

13.2 We will defend and compensate you for third-party claims that the qypu software itself (not your content or AI outputs you choose to publish) infringes intellectual property rights.

14. Suspension and termination

14.1 You may stop using qypu and close your workspace at any time.

14.2 We may end these Terms on 30 days' notice, or immediately if you materially breach them and do not fix the breach within 14 days of notice (or immediately for serious or repeated breaches of the Acceptable Use or Content policies).

14.3 After closure you have 30 days to export your data. We then delete it as described in the Data Retention and Deletion Policy.

15. Changes to these Terms

15.1 We will give at least 30 days' notice of material changes by email and on our change log. If you do not agree, you may cancel before the change takes effect and receive a pro-rata refund of prepaid fees.

15.2 We may make non-material changes (for example, fixing typos) at any time and record them in the change log.

16. Law and disputes

16.1 Governing law and courts: [GOVERNING LAW AND FORUM — counsel to decide after entity choice].

16.2 Before starting proceedings, each party will try in good faith for 30 days to resolve the dispute through the Complaints and Contact process.

16.3 Where you are in a jurisdiction listed in the Jurisdiction Annex of the Privacy Notice, any mandatory local rule on forum or consumer protection applies.

17. General

17.1 These Terms, the policies they name, and your order are the whole agreement on their subject.

17.2 If a court finds part of these Terms unenforceable, the rest stays in force.

17.3 Neither party may assign these Terms without the other's consent, except to a successor of its whole business who agrees to be bound by them.

17.4 Notices to us go to [CONTACT EMAIL]. Notices to you go to the account owner's email.

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review.

Privacy Notice

Version 0.1.0 · effective: DRAFT

In one line: What personal data we collect, why, who helps us process it, how long we keep it, and how you use your rights, with annexes for each country we serve.

The short version

• We collect what we need to run qypu: account details, the content you give us, data from channels you connect, and security logs. (Full text, section 3)
• For your workspace content, your business decides how it is used and we follow your instructions. For our own website and accounts, we decide. (Section 2)
• We never sell personal data. We do not use it for targeted advertising, and we do not use your content to train AI models. (Section 5)
• AI providers process content to produce drafts. They are bound by contract and listed on our Subprocessors page. (Sections 4 and 6)
• We keep data only as long as we need it. When you disconnect a channel, we delete its access tokens straight away. (Section 8)
• You can ask to see, correct, delete, or move your data, and to object. We reply within the time your local law sets. (Section 10)
• Some data is stored outside your country. We use legal safeguards for those transfers. (Section 9)
• Country-specific rights are in the annexes at the end. (Annexes A to H)

Full text

1. Who we are

[ENTITY NAME], of [REGISTERED ADDRESS], runs qypu at qypu.ai and app.qypu.ai. Contact our privacy team at [CONTACT EMAIL]. [DATA PROTECTION OFFICER / PRIVACY OFFICER — name and contact, see Counsel flags.] [EU, UK, AND SWISS REPRESENTATIVES — if required.]

2. Our role

2.1 Controller. We are the controller for personal data about website visitors, people who contact us, and the account owners and Authorised Users of our customers (account, billing, and security data).

2.2 Processor or service provider. For personal data inside a customer's workspace (for example, names in brand content, comments on the customer's channels, or staff names), the customer is the controller and we are its processor (in US state law terms, its service provider). The Data Processing Addendum governs that processing. If you are a customer of one of our customers, contact that business first; we will help them respond.

3. What we collect

• Account data: name, work email, business name, role, sign-in records (through WorkOS), and billing details (through our payment provider).
• Workspace content: Brand Kit answers, hard facts, never-say lists, uploaded images, audio, and video, drafts, edits, comments, signatures, and Authorisation records.
• Connected channel data: access tokens and the profile, page, post, comment, and insight data covered by the permissions you grant on Meta (Facebook and Instagram), TikTok, LinkedIn, Google (YouTube), and other platforms you choose.
• Voice and likeness data: only if you choose to use voice or likeness features and give the consent described in our Voice and Likeness Consent Policy.
• Usage and security data: IP address, device data, browser data, audit logs, error reports (Sentry), and rate-limit records (Upstash).
• Communications: messages you send us, and support notes.
• Website data: strictly necessary cookies only, unless you accept optional cookies (see the Cookie Notice).

We do not ask for sensitive data (such as health, religion, or political opinions) and our Content Policy forbids using qypu to target people on those grounds.

4. Why we use it (and our legal bases)

5. What we do not do

• We do not sell personal data, or "share" it for cross-context behavioural advertising as US state laws define those terms.
• We do not use workspace content or platform data to train or fine-tune AI models.
• We do not use platform data for advertising profiles, data brokering, or surveillance.
• We do not make decisions about people using AI alone that have legal or similarly significant effects on them.

6. Who we share it with

• Subprocessors that host, store, secure, or process data for us (listed with locations on our Subprocessors page).
• The platforms you instruct us to publish to. Once a post is published, the platform's own privacy policy applies.
• Professional advisers under confidentiality.
• Authorities, only where the law requires it (see our Government Requests page).
• A buyer of our business, under equal protections, with notice to you.

7. Google, YouTube, Meta, TikTok, and LinkedIn data

7.1 Our use of information received from Google APIs follows the Google API Services User Data Policy, including the Limited Use requirements. By connecting YouTube you also agree to the YouTube Terms of Service, and Google's handling is described in the Google Privacy Policy. You can revoke access in your Google security settings.

7.2 We use platform data only to provide the features you use, we keep it no longer than the platform allows, and we delete it when you disconnect or when the platform requires (see the Data Retention and Deletion Policy).

8. How long we keep it

See the Data Retention and Deletion Policy for the full table. In short: access tokens are deleted when you disconnect; workspace content is deleted within 30 days after you close your workspace; billing records are kept as long as tax law requires (usually 6 to 10 years); security logs are kept for up to 12 months.

9. International transfers

9.1 Our main processing locations are listed on the Subprocessors page. [CURRENT DATABASE REGION: Singapore; TARGET REGION: to be decided — see Security Overview.]

9.2 When we transfer personal data out of the EU, EEA, UK, or Switzerland, we use an adequacy decision (including the EU–US Data Privacy Framework and its UK and Swiss extensions where the recipient is certified), or the EU Standard Contractual Clauses with the UK Addendum or Swiss amendments, plus a transfer risk assessment.

9.3 For other countries, we use contracts that give comparable protection, as the annexes describe.

10. Your rights

10.1 Depending on where you live, you can ask us to: confirm whether we hold your data and give you a copy; correct it; delete it; restrict or object to its use; give it to you or another provider in a portable format; and withdraw consent at any time.

10.2 Send requests to [CONTACT EMAIL]. We may need to verify your identity. We will not charge you unless the law allows a fee for clearly excessive requests.

10.3 We reply within the time your local law sets (for example, 1 month in the EU and the UK, 30 days in Canada and Switzerland, 20 working days in New Zealand, and 45 days in California), and tell you if we need an extension the law permits.

10.4 You can complain to us, and you can complain to your data protection authority at any time (see the annexes).

11. Security

We protect data with the measures in our Security Overview. If a breach puts your rights at risk, we will tell you and the regulator as the law requires (see the Incident and Breach Notification Policy).

12. Children

qypu is not for children. We do not knowingly collect children's personal data, except where a customer includes a child in content with a parent's or guardian's consent, as our Children and Minors Policy requires.

13. Changes

We will post changes here with a new version number and record them in the change log. For material changes, we will email account owners at least 30 days in advance.

Annex A — United States

• Who this covers: residents of California, Colorado, Connecticut, Delaware, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah, Virginia, and other states with similar laws, where those laws apply to us.
• Categories collected (last 12 months): identifiers; commercial information (plan and billing); internet activity (logs); audio and visual information (media you upload); professional information (role); and inferences limited to service features (for example, best posting times for your channel).
• Sources: you, your business, platforms you connect, and our service providers.
• Sale and sharing: we do not sell personal information or share it for cross-context behavioural advertising, and we have not done so in the last 12 months. We honour Global Privacy Control signals as an opt-out.
• Sensitive personal information: we do not use it to infer characteristics. Voice data used for voice features is handled only with consent (and, where Illinois, Texas, or Washington biometric laws apply, with the written release those laws require).
• Your rights: know, access, correct, delete, portability, opt out of sale, sharing, targeted advertising, and profiling, and limit use of sensitive data; appeal a refusal by replying to our decision. We do not discriminate against you for using your rights. An authorised agent may act for you with proof.
• Children (COPPA): we do not set out to collect personal information online from children under 13.

Annex B — Canada (including Quebec)

• PIPEDA and provincial laws (Alberta and British Columbia PIPA, and Quebec's Act respecting the protection of personal information in the private sector, as amended by Law 25) apply.
• Our person in charge of the protection of personal information is [NAME AND TITLE] at [CONTACT EMAIL].
• We collect with consent appropriate to the sensitivity of the data. You may withdraw consent subject to legal and contractual limits.
• Quebec: we tell you when we use technology that can identify, locate, or profile you, and how to turn it off; we conduct a privacy impact assessment before transferring personal information outside Quebec; and you can ask for computerised personal information in a structured, commonly used format.
• Complaints: the Office of the Privacy Commissioner of Canada, or the Commission d'accès à l'information du Québec.
• Our marketing emails follow Canada's Anti-Spam Legislation (CASL): we send them only with consent, identify ourselves, and include an unsubscribe link that works within 10 business days.

Annex C — United Kingdom

• UK GDPR, the Data Protection Act 2018, and the Privacy and Electronic Communications Regulations (PECR) apply, as amended by the Data (Use and Access) Act 2025.
• Our UK representative under UK GDPR Article 27: [NAME AND ADDRESS, if required].
• You can complain to us first; we acknowledge complaints within 30 days. You can also complain to the Information Commissioner's Office (ico.org.uk).

Annex D — European Union and EEA

• The GDPR and national laws implementing the ePrivacy Directive apply.
• Our EU representative under GDPR Article 27: [NAME AND ADDRESS, if required].
• You can complain to the supervisory authority where you live or work, or where the alleged breach occurred.
• AI transparency obligations under the EU AI Act are covered in our AI Transparency and Disclosure Policy.

Annex E — Switzerland

• The revised Federal Act on Data Protection (revFADP) applies.
• Our Swiss representative under Article 14 revFADP: [NAME AND ADDRESS, if required].
• Transfers follow the Federal Council's list of adequate countries, the Swiss–US Data Privacy Framework, or the EU Standard Contractual Clauses with Swiss amendments.
• You can complain to the Federal Data Protection and Information Commissioner (FDPIC).

Annex F — Singapore

• The Personal Data Protection Act 2012 (PDPA) applies.
• Our Data Protection Officer: [NAME] at [CONTACT EMAIL].
• We notify the Personal Data Protection Commission within 3 calendar days of assessing that a notifiable breach occurred, and affected people where the PDPA requires.
• We check the Do Not Call Registry before sending marketing messages to Singapore telephone numbers.
• You can complain to the PDPC.

Annex G — Australia

• The Privacy Act 1988 and the Australian Privacy Principles (APPs) apply, including the 2024 amendments.
• You can access and correct your personal information under APPs 12 and 13.
• Overseas recipients: our subprocessors are located in the countries listed on the Subprocessors page. We take reasonable steps under APP 8 to ensure they handle your data consistently with the APPs.
• Automated decisions: we do not use computer programs to make decisions that significantly affect your rights or interests without human involvement. If this changes, we will describe it here before the APP 1.7 obligations commence on 10 December 2026.
• Breaches: we follow the Notifiable Data Breaches scheme.
• Complaints: contact us first. If you are not satisfied within 30 days, contact the Office of the Australian Information Commissioner (oaic.gov.au).
• Our marketing emails follow the Spam Act 2003.

Annex H — New Zealand

• The Privacy Act 2020 and its Information Privacy Principles (IPPs) apply.
• Our Privacy Officer: [NAME] at [CONTACT EMAIL].
• When we collect personal information about you from someone else (for example, a customer naming you in content), we take reasonable steps under IPP 3A to make sure you know, unless an exception applies.
• Cross-border disclosures follow IPP 12.
• Breaches likely to cause serious harm are notified to the Privacy Commissioner and affected people as soon as practicable.
• Complaints: the Office of the Privacy Commissioner (privacy.org.nz).

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review, replacing the earlier draft at /legal/privacy.

Cookie Notice

Version 0.1.0 · effective: DRAFT

In one line: We use only the cookies the site needs to work. If we ever add optional cookies, we will ask first, and "No" will be as easy as "Yes".

The short version

• Today qypu.ai uses only strictly necessary cookies: sign-in, security, and load balancing. (Full text, section 2)
• We use no advertising cookies, no cross-site tracking, and no third-party analytics cookies. (Section 3)
• If we add optional cookies later, we will ask before setting them. Accept and Reject will look the same, and you can change your mind at any time. (Section 4)
• We treat Global Privacy Control signals as an opt-out. (Section 5)

Full text

1. What cookies are

Cookies are small files a website stores in your browser. Similar tools include local storage and pixels. This notice covers all of them.

2. Cookies we use now

[COOKIE TABLE — engineering to confirm each name and duration from the live site before publication.]

3. Cookies we do not use

We do not use advertising, retargeting, social media pixels, or cross-site tracking cookies on qypu.ai or app.qypu.ai.

4. If we add optional cookies

Before we set any non-essential cookie, we will show a choice with equal "Accept" and "Reject" buttons, list each cookie here, and record your choice. You can change it at any time from the footer link "Cookie settings".

5. Global Privacy Control and Do Not Track

We treat a Global Privacy Control signal as a valid opt-out of sale, sharing, and targeted advertising where the law gives it that effect. Browsers' "Do Not Track" setting has no agreed standard; because we do no tracking, it changes nothing.

6. Contact

Questions: [CONTACT EMAIL].

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review.

Data Processing Addendum

Version 0.1.0 · effective: DRAFT

In one line: The contract terms that apply when we process personal data for your business. It covers instructions, security, subprocessors, breaches, transfers, and deletion.

The short version

• This addendum is part of our Terms. It applies whenever we process personal data on your behalf. (Full text, section 1)
• We act only on your documented instructions, and the main instruction is "run the service as configured". (Section 3)
• Our staff keep your data confidential. We protect it with the measures in Annex 2. (Sections 4 and 5)
• We use only the subprocessors on our list, and we give you 30 days' notice before adding one. You may object. (Section 6)
• We tell you about a personal data breach without undue delay, and within 48 hours of confirming it. (Section 7)
• We help you answer people's requests and carry out impact assessments. (Section 8)
• For international transfers we use the EU Standard Contractual Clauses, the UK Addendum, and the Swiss amendments. (Section 9)
• When the service ends, we delete or return your data within 30 days, unless the law requires us to keep it. (Section 10)

Full text

1. Scope and order of precedence

1.1 This Data Processing Addendum ("DPA") forms part of the agreement between [ENTITY NAME] ("Processor") and the Customer ("Controller") for qypu (the "Agreement").

1.2 It applies to Personal Data that we process on the Customer's behalf ("Customer Personal Data"). Terms such as "personal data", "processing", "controller", "processor", "data subject", and "supervisory authority" have the meanings in the GDPR, or the nearest equivalent under other Data Protection Laws.

1.3 "Data Protection Laws" means all privacy and data protection laws that apply to the processing, including: the GDPR; the UK GDPR and the Data Protection Act 2018; the revFADP; PIPEDA and Quebec Law 25; US state privacy laws (including the CCPA as amended by the CPRA); the Singapore PDPA; the Australian Privacy Act 1988; and the New Zealand Privacy Act 2020.

1.4 If this DPA conflicts with the Agreement, this DPA wins. If it conflicts with the Standard Contractual Clauses, the Clauses win.

2. Details of processing

Annex 1 describes the subject matter, duration, nature, and purpose of processing, the types of personal data, and the categories of data subjects.

3. Instructions

3.1 We process Customer Personal Data only on the Customer's documented instructions, including with regard to transfers, unless the law requires otherwise; in that case we will tell the Customer first, unless the law forbids it.

3.2 The Agreement, the Customer's configuration of qypu, and signed posts are the Customer's complete instructions at the time of signing. Further instructions must be in writing and consistent with the Agreement.

3.3 We will tell the Customer promptly if we believe an instruction breaks Data Protection Laws.

3.4 US service provider terms. We will not sell or share Customer Personal Data; retain, use, or disclose it outside the direct business relationship or for any purpose other than the business purposes in the Agreement; or combine it with personal data from other sources except as the CCPA permits. We will comply with the CCPA and give the same level of privacy protection it requires, and we will notify the Customer if we can no longer meet our obligations. The Customer may take reasonable steps to stop and remedy unauthorised use.

4. Confidentiality

Everyone we authorise to process Customer Personal Data is bound by confidentiality obligations.

5. Security

We implement the technical and organisational measures in Annex 2 and keep them appropriate to the risk. We may update them, provided the update does not reduce overall protection.

6. Subprocessors

6.1 The Customer gives general authorisation for us to use the subprocessors listed at qypu.ai/trust/subprocessors.

6.2 We will give at least 30 days' notice of a new subprocessor by updating that page and emailing subscribers. The Customer may object, giving data protection reasons, during that period. If we cannot resolve the objection, the Customer may terminate the affected service and receive a pro-rata refund of prepaid fees.

6.3 We impose data protection obligations on each subprocessor that are no less protective than this DPA, and we remain liable for their performance.

7. Personal data breaches

7.1 We will notify the Customer without undue delay, and in any case within 48 hours, after we confirm a personal data breach affecting Customer Personal Data.

7.2 The notice will include what we know about the nature of the breach, the categories and approximate number of people and records affected, likely consequences, the measures taken or proposed, and a contact point. We will send further information as it becomes available.

7.3 Notifying a breach is not an admission of fault.

8. Assistance

8.1 Taking into account the nature of the processing, we will help the Customer respond to data subject requests, mainly through self-service tools in qypu.

8.2 We will provide reasonable help with data protection impact assessments, prior consultations, and security obligations.

8.3 We will forward to the Customer any request we receive directly from a data subject about Customer Personal Data, without responding beyond acknowledging it, unless the Customer authorises us.

9. International transfers

9.1 Where Customer Personal Data subject to the GDPR is transferred to a country without an adequacy decision, the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module 2 (controller to processor) and, where we act as a subprocessor, Module 3, are incorporated by reference, with: optional Clause 7 included; Clause 9 option 2 (general authorisation, 30 days' notice); Clause 11 optional language omitted; Clause 17 and 18 governed by the law and courts of [EU MEMBER STATE — counsel to choose]; and the Annexes completed by Annexes 1 and 2 of this DPA.

9.2 For UK data, the International Data Transfer Addendum to the EU SCCs issued by the ICO (version B1.0) applies, with Table 1 to 3 completed from this DPA and either party able to end it as Section 19 permits.

9.3 For Swiss data, the SCCs apply with these changes: the FDPIC is the competent supervisory authority; "Member State" includes Switzerland so Swiss data subjects can sue where they live; and references to the GDPR include the revFADP.

9.4 Where a recipient is certified under the EU–US Data Privacy Framework (or its UK or Swiss extensions), we may rely on that certification instead.

9.5 For transfers from other jurisdictions (for example, out of Quebec, Singapore, Australia, or New Zealand), we provide comparable contractual protection and support any assessment the law requires.

10. Return and deletion

Within 30 days after the Agreement ends, we will delete Customer Personal Data, or return it in a portable format if the Customer asks before the end date, unless the law requires us to keep it. Backups roll off within a further 35 days.

11. Audits

11.1 We will make available information reasonably needed to demonstrate compliance with this DPA, including our Security Overview, policies, and answers to a reasonable security questionnaire once a year.

11.2 If that information is not enough, or a regulator requires it, the Customer may audit us on 30 days' notice, during business hours, at its own cost, through an independent auditor bound by confidentiality, no more than once in 12 months unless a breach has occurred.

12. Liability

Liability under this DPA is subject to the liability terms of the Agreement, except where Data Protection Laws or the SCCs do not allow that.

Annex 1 — Details of processing

• Subject matter and duration: providing qypu for the term of the Agreement.
• Nature and purpose: hosting, storing, generating drafts with AI, running Checks, publishing signed content to connected channels, collecting results, and support.
• Data subjects: the Customer's Authorised Users, staff, customers, and followers who appear in content, comments, or messages; people whose voice or likeness the Customer licenses.
• Personal data: names; handles; profile images; messages and comments; contact details; voice and image data (only with consent); and usage data.
• Special categories: none intended. The Customer must not upload special category data unless agreed in writing.
• Frequency: continuous.
• Retention: as in the Data Retention and Deletion Policy.

Annex 2 — Technical and organisational measures

See the Security Overview at qypu.ai/trust/security. Each measure is labelled "In place" or "Planned". Only measures labelled "In place" form part of this Annex until we update it.

Annex 3 — Subprocessors

See qypu.ai/trust/subprocessors (machine-readable at /trust/subprocessors.json).

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review.

AI Transparency and Disclosure

Version 0.1.0 · effective: DRAFT

In one line: Where we use AI, which providers we use, how we label AI content for your audience, and what AI is never allowed to do on its own.

The short version

• AI drafts text, images, and (later) audio for you. A person in your business signs every post before we publish it. (Full text, sections 2 and 4)
• When you talk to our onboarding assistant, we tell you it is AI. (Section 3)
• Images and video we generate carry Content Credentials (C2PA) and an AI marker in the file. We never remove or fake these marks. (Section 5)
• We switch on each platform's AI label where it applies, for example Meta's "AI info", TikTok's AI-generated label, and YouTube's altered or synthetic content setting. (Section 6)
• AI steps have no power to act alone. They cannot publish, send messages, read your passwords or tokens, or spend money. (Section 7)
• We do not train AI models on your content, and our providers may not either. (Section 8)
• AI can be wrong. Our Checks catch many problems, but you make the final call. (Section 9)

Full text

1. Why this page exists

We want you, your staff, your audience, and platform reviewers to know exactly where AI is involved in qypu. This page also explains how we meet AI transparency rules, including Article 50 of the EU AI Act, platform policies, and consumer protection law on endorsements and reviews.

2. Where we use AI

3. Talking to AI

Our onboarding interview is run by an AI assistant. We say so at the start and on screen throughout. You can ask for a person at any time at [CONTACT EMAIL].

4. Human sign-off

No AI output is published, sent, or relied on in qypu without a named person signing it. See the Human Review and Sign-off Policy.

5. Marks inside the file (provenance)

5.1 Media we generate carries a C2PA Content Credentials manifest stating that AI was used, and the IPTC digital source type "trainedAlgorithmicMedia" (or "compositeWithTrainedAlgorithmicMedia" for edits).

5.2 We never strip, replace, or forge provenance data from media you upload or we generate, and we never add fake camera data.

5.3 Some platforms remove file metadata on upload. That is why we also use the platform label in section 6.

6. Labels your audience sees

You may add more disclosure. You may not remove a label we set, unless the content is not realistic AI content and the platform rules allow it.

7. What AI may never do on its own

• Publish, post, send a direct message, or reply.
• Read access tokens, passwords, or payment data.
• Spend money, change billing, or change who can sign.
• Follow links or instructions found in comments, web pages, or uploaded files. We treat that text as untrusted data.

Drafting steps run with no tools at all. This is "least privilege": each step gets only what its task needs. (In place in code for drafting stages; being extended to every stage — Planned until complete.)

8. Training and data use

8.1 We do not use your content, your channel data, or your audience's data to train or fine-tune AI models.

8.2 Our contracts with AI providers prohibit them from training on data we send. Where a provider offers zero data retention for our account, we use it; the Subprocessors page shows each provider's retention.

9. Accuracy and limits

9.1 AI can produce wrong facts, wrong tone, or content that looks like someone else's work. Our Checks compare each draft with your hard facts and never-say list, scan for risky claims, and enforce platform rules.

9.2 Checks do not guarantee accuracy. You remain responsible for what you sign.

9.3 We plan to publish how often Checks catch problems in a fixed test set, and how often they miss them. (Planned)

10. What we do not offer

We do not offer fake accounts, undisclosed AI personas, fake reviews or testimonials, AI detector evasion, or posting to accounts our customers do not own or control.

11. Machine-readable version

A machine-readable summary is at /trust/ai-disclosure.json.

12. Legal notes

12.1 EU AI Act Article 50. We disclose AI interaction (Art. 50(1)), mark generated media in a machine-readable way (Art. 50(2)), and give customers the tools to disclose deep fakes (Art. 50(4)). Published text is signed by a named person who holds editorial responsibility; where text informs the public on matters of public interest, we still recommend disclosure.

12.2 Endorsements and reviews. AI must never write fake reviews, testimonials, or endorsements (US FTC Rule on Consumer Reviews and Testimonials, 16 CFR Part 465; FTC Endorsement Guides, 16 CFR Part 255; UK DMCC Act 2024; EU Unfair Commercial Practices Directive). Paid partnerships must carry the platform's paid-partnership label.

12.3 Bots. Automated replies that try to sell to people in California must say they are automated (California Business and Professions Code §17941). Replies in qypu are signed by a person before sending.

Change log

• 2026-10-10 · 0.1.0 · First full draft, replacing the earlier short page at /legal/ai-transparency.

Acceptable Use Policy

Version 0.1.0 · effective: DRAFT

In one line: What you may not use qypu for. Breaking these rules can lead us to pause a post, a channel, or your workspace.

The short version

• Use qypu only for your own business, on channels you own or are authorised to run. (Full text, section 2)
• Do not use it to deceive people: no fake reviews, fake accounts, hidden ads, or impersonation. (Section 3)
• Do not use it for illegal, harmful, hateful, or sexual content, or to target children. (Section 4)
• No political campaigning, and no content about elections or candidates. (Section 4 and the Content Policy)
• Do not attack, overload, or reverse-engineer the service, or try to get around our Checks. (Section 5)
• If you break these rules, we may pause content or accounts. We tell you why, and you can appeal. (Section 6)

Full text

1. Who this applies to

This policy applies to every Customer and Authorised User of qypu, and to anything created, uploaded, or published through it.

2. Your own business, your own channels

2.1 Use qypu only to promote or run your own business, or a business you are authorised in writing to represent.

2.2 Connect only channels that you own, or that the owner has authorised you to manage. Every channel must be clearly identified as the business it represents.

3. No deception

You must not use qypu to:

• create or run fake, automated, or undisclosed accounts, or coordinate accounts to make something look more popular than it is;
• write, buy, or post fake reviews, testimonials, or endorsements, or reviews by staff or relatives that do not say so;
• hide paid partnerships, sponsorship, or affiliate links;
• impersonate a person, brand, or authority, or imply an endorsement you do not have;
• make health, financial, environmental, or other claims you cannot support with evidence;
• remove or hide AI labels or Content Credentials that qypu adds.

4. Prohibited content

You must not use qypu to create or publish content that:

• is illegal where you, your audience, or the platform operate;
• sexualises anyone, includes nudity, or involves any minor in a sexual, harmful, or exploitative way;
• promotes violence, terrorism, self-harm, or eating disorders;
• harasses, bullies, threatens, or doxxes anyone;
• attacks people based on race, ethnicity, national origin, religion, caste, sex, gender identity, sexual orientation, disability, age, or serious disease;
• is political, election-related, or about social issues in the sense of the Content and Political Content Policy;
• promotes weapons, illegal drugs, tobacco, vaping products, gambling, or adult services, or regulated products where the law or platform restricts them;
• infringes copyright, trademarks, privacy, or publicity rights;
• uses a real person's voice or likeness without the consent described in the Voice and Likeness Consent Policy;
• is targeted at children under 16, or collects their data.

5. Protecting the service

You must not:

• probe, scan, or test our systems, except under the Vulnerability Disclosure Policy;
• overload, scrape, or reverse-engineer the service, except where the law allows despite this clause;
• try to get around Checks, rate limits, sign-off, or usage limits, including by prompt injection;
• share sign-in details, or let someone you have not added as an Authorised User sign posts;
• resell qypu without our written agreement.

6. What happens if rules are broken

6.1 We may block a draft, unpublish a post we published for you where the platform allows, pause a channel, or suspend a workspace. We act in proportion to the risk.

6.2 We tell you what we did and why, unless the law or a safety risk prevents it. You may appeal through the Complaints and Contact page; a person who was not involved in the first decision reviews the appeal.

6.3 We may report illegal content to the authorities and to platforms, where the law requires or allows it.

7. Reporting misuse

Anyone can report misuse of qypu to [CONTACT EMAIL] with "Abuse report" in the subject line. We acknowledge reports within 2 working days.

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review.

Content and Political Content Policy

Version 0.1.0 · effective: DRAFT

In one line: What content qypu will and will not draft. We do not produce political, election, or social-issue content for anyone, at any price.

The short version

• qypu drafts content that promotes your business: your products, services, team, events, and community. (Full text, section 1)
• We do not draft or publish political content: no candidates, parties, elections, referendums, ballot measures, or lobbying. (Section 2)
• We also avoid hot-button social issues as campaign topics. You can still say you are closed for a public holiday or that you support a local charity run. (Section 3)
• Sensitive claims, such as health, money, or green claims, need evidence in your hard facts. (Section 4)
• Our Checks block or flag content that breaks these rules. A person at qypu reviews disputed cases. (Section 5)

Full text

1. What qypu is for

SOE Studio drafts social content that promotes a small business's own products, services, people, events, offers, and community involvement, in that business's Voice and within its Brand Kit.

2. Political content ban

2.1 qypu does not create, edit, schedule, or publish political content for any customer. Political content means content that:

• supports, opposes, or mentions a candidate, political party, or holder of political office in that capacity;
• relates to an election, referendum, ballot measure, or voter registration, turnout, or voting methods;
• seeks to influence legislation, regulation, or government policy (lobbying); or
• is political advertising under the law where it is shown, including the EU Regulation on the transparency and targeting of political advertising (EU) 2024/900.

2.2 This ban applies even if the customer is a political organisation. We do not accept political parties, campaigns, or candidates as customers.

2.3 Neutral civic information is allowed only if it contains no opinion and links to an official source, for example "Our shop is a polling station on Thursday."

3. Social issues

3.1 Platforms treat some topics as "social issues" and require extra authorisation to run ads about them. We do not draft content that advocates a position on these topics, such as immigration, abortion, guns, or climate policy.

3.2 A business may mention its own community work (for example, "We raised £300 for the food bank") if it is factual and does not advocate for a policy.

4. Claims that need evidence

5. How we enforce it

5.1 Checks run on every draft. They block content in banned categories and flag content close to the line.

5.2 Flagged items go to you with the reason. If you disagree, you can ask for a human review by qypu staff. We aim to answer within 2 working days.

5.3 Repeated attempts to publish banned content may lead to suspension under the Acceptable Use Policy.

6. Real people and events

Do not draft content about real people (other than your own staff with consent) or about news events involving harm, such as disasters or crimes, unless the post is a factual business notice (for example, "We are closed today because of the flood warning").

Change log

• 2026-10-10 · 0.1.0 · First draft for counsel review.

Brand Facts and Licence

Version 0.1.0 · effective: DRAFT

In one line: How you tell qypu what is true about your business, what it must never say, and how much creative freedom the AI has.

The short version

• Hard facts are the things you confirm are true: prices, opening hours, products, awards, and proof. Drafts may state specifics only from this list. (Full text, section 2)
• Never-say list holds words, claims, and topics you never want used. Checks block any draft that uses them. (Section 3)
• Licence level sets how much creative freedom the AI has, from "facts only" to "storytelling". It never allows invented facts. (Section 4)
• You own these settings and can change them at any time. Changes apply to new drafts straight away. (Section 5)
• You are responsible for keeping hard facts true and up to date. (Section 6)

Full text

1. Why this matters

AI is good at fluent sentences and bad at knowing what is true about your business. Brand facts close that gap. They are the only source of specific claims in your posts.

2. Hard facts

2.1 A hard fact is a statement you confirm is true and can support, for example "Open Tuesday to Sunday, 08:00 to 16:00", "Flat white £3.20", or "Gas Safe registered, number 123456".

2.2 Each draft records which hard facts it used. Checks flag any specific claim (a number, a price, a date, an award, a certification, or a comparison) that does not come from your hard facts.

2.3 Hard facts can carry an expiry date, for example a seasonal offer. After that date, drafts stop using them.

3. Never-say list

3.1 The never-say list holds words, phrases, claims, competitors, and topics you do not want in your content, for example "cheapest in town" or a former product name.

3.2 Checks block drafts that contain items on the list, including obvious variants. Blocked drafts come to you with the reason.

3.3 qypu adds a base never-say list for every workspace from the Content and Political Content Policy and platform rules. You cannot remove those items.

4. Licence level

4.1 The licence level sets how far the AI may go beyond your exact words. Current draft levels (names may change before launch):

4.2 No level allows invented facts, invented customers, invented quotes, or invented reviews.

4.3 Storytelling must not mislead. A story must not be presented as a real event unless it is one of your hard facts.

5. Your control

You can edit hard facts, the never-say list, and the licence level in the Brand Kit at any time. Edits apply to new drafts at once. Drafts already signed are not changed; we show you any signed post that conflicts with an edit before it is published.

6. Your responsibility

You are responsible for the accuracy of hard facts and for having the rights to the brand assets you upload. Our Checks reduce the risk of errors, but they cannot know facts you have not told us.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Human Review and Sign-off

Version 0.1.0 · effective: DRAFT

In one line: Nothing goes out without a named person in your business signing it. Here is how signing works, and what we record.

The short version

• Every post, reply, and message needs a signature from a person you have named as a signer. (Full text, section 2)
• Signing means you have read the final version, including any image, video, or audio. There is no "sign all" button. (Section 3)
• Any change after signing cancels the signature. The post goes back for a new one. (Section 4)
• We keep a record of who signed what, when, and which version, so you can always check what was published and why. (Section 5)
• You can return a draft with a comment at any time. (Section 6)

Full text

1. Purpose

Human sign-off keeps a real person responsible for everything published in a business's name. It also supports AI transparency rules that recognise human editorial control.

2. Who can sign

2.1 The workspace owner names signers. A signer must be an Authorised User aged 18 or over who is authorised by the business to approve public communications.

2.2 Each signer signs in with their own account. Shared accounts cannot sign.

3. What signing means

3.1 Signing confirms that the signer has reviewed the final content, including captions, media, links, tags, platform labels, and scheduled time, and approves it for publication on the named channel.

3.2 qypu shows the signer the full content and every flag from Checks before they sign. Flags must be opened before signing.

3.3 There is no bulk approval. Each post is signed on its own.

4. Changes after signing

Any change to content, media, channel, or schedule after signing voids the signature. The post returns to Draft and needs a new signature. Small automatic changes made by a platform at upload (such as image compression) do not void it.

5. What we record (provenance record)

For each published post we keep: the draft versions; the hard facts used; the Checks run and their results; the signer, time, and version signed; the channel and Authorisation record used; and the platform's post ID. We keep this record for the retention period in the Data Retention and Deletion Policy, so you can show what was published and who approved it.

6. Returning a draft

Signers can return a draft with a comment. The comment guides the next draft. Returned drafts are never published.

7. Scheduled posts

Signed posts publish at the scheduled time. You can unschedule a signed post until it is published.

8. Platform reviewers

Platform reviewers can see this flow in a test workspace on request at [CONTACT EMAIL].

Change log

• 2026-10-10 · 0.1.0 · First draft.

Account Connection and Authorisation

Version 0.1.0 · effective: DRAFT

In one line: How you connect your social channels to qypu, what access you give us, what we record, and how to take it back at any time.

The short version

• You connect channels with the platform's own "Log in with" screen (OAuth). We never ask for or store your passwords. (Full text, section 2)
• You see the exact permissions before you agree. We ask only for those we need. (Section 3)
• We keep a signed Authorisation record: who connected the channel, when, which permissions, and for which workspace. (Section 4)
• Access tokens are stored encrypted. (Section 5)
• You can disconnect at any time, in qypu or on the platform. We delete the tokens straight away. (Section 6)
• If the platform tells us you removed qypu, or asks us to delete data, we do it. (Section 7)

Full text

1. Scope

This policy covers how qypu connects to Meta (Facebook and Instagram), TikTok, LinkedIn, Google (YouTube), and any other platform we add.

2. Connection method

2.1 Channels are connected through the platform's official OAuth flow. You sign in on the platform's own page. qypu never sees your platform password.

2.2 A channel owner can also be invited by email to connect a channel. The invitation link is single-use, expires, and can be revoked.

3. Permissions

3.1 Before you agree, the platform shows the permissions requested. We request only the permissions needed for the features you use: publishing posts, reading basic profile and page information, and reading insights and comments for your results.

3.2 We use each permission only for the purpose shown in our platform app review submissions.

4. Authorisation record

4.1 When you connect a channel, qypu creates an Authorisation record. It contains the person who connected the channel, the workspace, the platform, the scopes granted, the time, and a signed confirmation of your authorisation for qypu to publish signed posts on that channel.

4.2 Authorisation records are kept for the life of the workspace plus the period in the retention policy, so you and the platform can verify that every post had authority.

5. Token security

5.1 Access and refresh tokens are encrypted at rest with authenticated encryption (AES-256-GCM). In place.

5.2 Per-workspace encryption keys bound to each record, and key rotation. Planned (code built; being connected).

5.3 Tokens are never shown in the interface, never sent to AI models, and filtered from logs and error reports. Log filtering: in place for the main paths; being extended to all platform callbacks (Planned until complete).

6. Disconnecting

6.1 You can disconnect a channel at any time in Settings, then Channels. We revoke the token with the platform where it supports revocation, and delete it from qypu immediately.

6.2 You can also remove qypu on the platform:

• Facebook and Instagram: Settings, then Apps and websites.
• Google and YouTube: Google Account, then Security, then Third-party connections.
• TikTok: Settings, then Security, then Manage app permissions.
• LinkedIn: Settings, then Data privacy, then Permitted services.

6.3 After disconnection, scheduled posts for that channel are cancelled and you are told.

7. Platform signals

7.1 We process Meta deauthorisation and data deletion callbacks. A deletion request returns a confirmation code and a status page at /legal/data-deletion.

7.2 We refresh or delete platform data within the time each platform's terms require (for example, YouTube API data that is not refreshed within 30 days is deleted).

8. Disclosed, client-owned channels only

qypu connects only channels owned by the customer business, or that it is authorised to manage, and that clearly represent that business.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Data Retention and Deletion

Version 0.1.0 · effective: DRAFT

In one line: How long we keep each kind of data, and how you, your audience, or a platform can ask us to delete it.

The short version

• We keep data only while we need it for the service, for security, or because the law requires it. (Full text, section 1)
• Disconnecting a channel deletes its tokens at once. (Section 2)
• Closing your workspace starts a 30-day export window; then we delete your content. Backups roll off within a further 35 days. (Sections 2 and 3)
• We keep billing records as long as tax law requires, and a short record that a deletion happened. (Section 2)
• Anyone can ask us to delete their data. Facebook and Instagram users can do it from their Facebook settings, and get a confirmation code. (Section 4)

Full text

1. Principles

We keep personal data for no longer than we need it for the purpose we collected it for, plus any period the law requires. We review this schedule every year.

2. Retention schedule

[PERIODS IN BRACKETS — counsel to confirm.]

3. Closing your workspace

3.1 The owner can close the workspace in Settings. Scheduled posts are cancelled and channels are disconnected.

3.2 You have 30 days to export your content in a common format (JSON and the original media files). After 30 days we delete it, except as section 2 says.

3.3 Published posts remain on the platforms. Delete them there, or ask us to delete them for you before you close the workspace.

4. Deletion requests

4.1 From a customer: in Settings, or by email to [CONTACT EMAIL] from the account owner's address.

4.2 From someone who appears in content, or comments on a channel: we pass the request to the business that controls the content and help it respond. If we hold data about you as controller, we act on it directly.

4.3 Facebook and Instagram users: remove qypu in Facebook Settings, then Apps and websites, and choose to send a deletion request. We return a confirmation code and a status page at /legal/data-deletion.

4.4 Google and YouTube users: revoke access in your Google Account; we then delete stored YouTube data within 7 days, or sooner where the YouTube API Services policies require.

4.5 We confirm completion of a deletion request, and tell you about any data we must keep and why.

5. Legal holds

If we receive a valid legal demand or need data to defend a legal claim, we may keep the specific data concerned until the matter ends.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Security Overview

Version 0.1.0 · effective: DRAFT

In one line: The security controls qypu has in place today, the ones still planned, and the gaps we know about. We hold no security certification yet.

The short version

• We hold no security certification. We do not claim SOC 2, ISO 27001, or similar. (Full text, section 1)
• Every control below is marked In place or Planned. We update this page when that changes. (Section 2)
• In place today: OAuth sign-in with no stored platform passwords, encrypted tokens, strict browser security headers, rate limits, staff access behind Cloudflare Access, and automated code and dependency scanning. (Section 3)
• Most important planned work: a separate database and storage for qypu, per-workspace encryption keys, a permanent audit log, and an independent penetration test. (Section 4)
• We publish what we watch, how fast we aim to recover, and who does what. (Sections 5 to 7)
• Found a problem? See the Vulnerability Disclosure Policy. (Section 8)

Full text

1. Our position

qypu is an early-stage service. We would rather show you an honest list than a badge. We hold no third-party security certification or attestation. When we start an audit, we will say so here, and we will not describe ourselves as "compliant" with a standard until an independent auditor says so.

2. How to read this page

• In place: running in the code on our main branch, and checked by tests or configuration review.
• Planned: designed or partly built, not yet relied on. No date unless stated.

3. Controls

4. Known gaps we are fixing

We keep an internal security audit and fix list. The most important open items, in order:

1. Separate qypu's database, storage, and vendor keys from the other product they are shared with today.
2. Connect per-workspace token encryption.
3. Store audit events permanently, not only in logs.
4. Enforce multi-factor authentication for all staff.
5. Commission an independent penetration test before we take paying customers at scale.

5. What we watch

We monitor errors, failed sign-ins, rate-limit hits, AI spend, token refresh failures, and publishing failures. Alerts go to the on-call person. A public status page is Planned.

6. Recovery targets (draft)

Signed, scheduled posts are not published while qypu is down. They publish when service returns, unless their time has passed by more than 2 hours; then we ask you again.

7. Who does what

Security is shared. See the "Who does what" page for the split between qypu, you, platforms, and our providers.

8. Post-quantum readiness

How we prepare for future quantum computers is on the Post-Quantum Readiness page (/trust/post-quantum).

9. Reporting a vulnerability

See the Vulnerability Disclosure Policy, or /.well-known/security.txt.

Change log

• 2026-10-10 · 0.1.0 · First draft, based on the internal security audit of 10 October 2026.

Post-Quantum Readiness

Version 0.1.0 · effective: DRAFT

In one line: How we prepare our encryption for future quantum computers, what is in place today, what is planned, and what nobody can do yet. There is no recognised post-quantum certification for a website, and we do not claim one.

The short version

• Future quantum computers may break some of the encryption the internet uses today. Someone could record encrypted data now and read it later. (Section 1)
• Most connections to qypu, and from qypu to the AI and social platforms we use, already use a post-quantum key exchange. (Section 3)
• Our plan to protect stored platform tokens and signed records with post-quantum methods is designed and built, but not yet in use. (Section 4)
• Some parts cannot be post-quantum yet, because they belong to other companies or to your browser. (Section 5)
• We follow the NIST standards FIPS 203, FIPS 204, and FIPS 205. (Section 6)
• No one issues a recognised "post-quantum certified" badge for a website. We do not claim one. (Section 7)

Full text

1. Why this matters

Encryption keeps your data private on the way to us and while we store it. Much of it relies on maths that a large quantum computer could solve. No such computer exists today. But an attacker could record encrypted traffic or steal encrypted files now, and decrypt them years later. This is called "record now, decrypt later".

The data most at risk is data that must stay secret for years: the tokens that let us post to your social accounts, your brand details, and the authorisations you sign. That is where we start.

2. How to read this page

• In place: running today, and checked by us.
• Planned: designed or built, not yet relied on. No date unless stated.
• Not yet possible: outside our control today. We say why and what we will do.

3. In place

These hops protect the key exchange. The certificates that prove a server's identity are still classical. That is a smaller risk, because an attacker would have to break them in real time, not later.

4. Planned

5. Not yet possible

6. Standards we follow

• FIPS 203 (ML-KEM): post-quantum key exchange, published by NIST in August 2024.
• FIPS 204 (ML-DSA): post-quantum signatures, NIST, August 2024.
• FIPS 205 (SLH-DSA): hash-based signatures, NIST, August 2024.
• Hybrid key exchange in TLS: the X25519MLKEM768 group used by browsers and our providers (IETF RFC 10024). ETSI TS 103 744 describes the same hybrid approach.
• Timelines: the UK NCSC asks organisations to finish planning by 2028, move the most important systems by 2031, and finish by 2035. A US executive order of June 2026 sets 2030 and 2031 for federal systems. We aim to be well ahead of both.

7. Certification

There is no recognised certification that says a website or service is "post-quantum secure". We do not claim one, and we will not use phrases such as "quantum-proof".

What does exist: NIST tests cryptographic modules under FIPS 140-3. In our check on 10 October 2026, post-quantum modules were in the NIST queue, but we could not confirm any validated module certificate that covers ML-KEM. The algorithms we use come from standard software libraries (OpenSSL 3.5 in Node.js). They are not a FIPS 140-3 validated module in our setup. If that changes, we will say so here.

8. Crypto-agility

Every encrypted item and signature we create carries a label that names its method and version. All our encryption code lives in one place. If a method is weakened, we can switch to a new one and re-protect stored data without rewriting the service. We review this page at least once a year and whenever the standards change.

9. Sources

• NIST, FIPS 203, 204, and 205 (August 2024): csrc.nist.gov
• NIST CMVP validated modules search: csrc.nist.gov/projects/cryptographic-module-validation-program
• UK NCSC, "Timelines for migration to post-quantum cryptography": ncsc.gov.uk/guidance/pqc-migration-timelines
• US Federal Register, "Securing the Nation Against Advanced Cryptographic Attacks" (25 June 2026)
• ETSI TS 103 744 V1.2.2, Quantum-safe Hybrid Key Establishment
• IETF RFC 10024, PQ/T Hybrid Key Agreement for TLS 1.3
• Vercel, "Vercel now supports post-quantum cryptography" (7 November 2025); Cloudflare SSL/TLS docs, "Post-quantum cryptography"
• Our own connection checks: OpenSSL 3.5.7, 10 October 2026

Change log

• 2026-10-10 - 0.1.0 - First draft, based on our post-quantum review and connection checks of 10 October 2026.

Vulnerability Disclosure Policy

Version 0.1.0 · effective: DRAFT

In one line: How to report a security problem to us, what we promise in return, and the rules that keep your research safe and legal.

The short version

• Email security@qypu.ai with what you found and how to reproduce it. (Full text, section 2)
• We reply within 2 working days and keep you updated. (Section 3)
• If you follow these rules in good faith, we will not take legal action against you. (Section 4)
• Do not access other people's data, disrupt the service, or publish before we fix it. (Section 5)
• We have no paid bug bounty yet. We are happy to credit you. (Section 6)

Full text

1. Scope

In scope: qypu.ai, app.qypu.ai, and our public API endpoints. Out of scope: admin.qypu.ai brute-force attempts, third-party platforms (report to them), denial-of-service tests, social engineering, and physical attacks.

2. How to report

Send a report to security@qypu.ai. Include the affected URL or component, steps to reproduce, impact, and your contact details. Please encrypt sensitive details if you can; [PGP KEY — planned].

3. Our commitments

• Acknowledge your report within 2 working days.
• Give an initial assessment within 7 days.
• Aim to fix critical issues within 7 days and high-severity issues within 30 days of confirmation.
• Tell you when the issue is fixed, and agree a disclosure date with you (normally within 90 days).

4. Safe harbour

If you make a good-faith effort to follow this policy, we will consider your research authorised, we will not pursue legal action against you, and we will not report you to authorities for it. If a third party takes action, we will make it known that your research was authorised. This does not bind other parties, such as platforms.

5. Rules

• Use only your own test accounts and test workspaces.
• Stop and tell us as soon as you reach personal data, tokens, or another customer's information. Do not keep, share, or use it.
• Do not degrade the service, send spam, or publish to real social channels.
• Do not publish details before the agreed date.

6. Recognition

We do not run a paid bug bounty yet. With your permission, we will credit you on our change log.

7. Machine-readable contact

/.well-known/security.txt (RFC 9116).

Change log

• 2026-10-10 · 0.1.0 · First draft.

Incident and Breach Notification

Version 0.1.0 · effective: DRAFT

In one line: What we do when something goes wrong with your data, and how fast we tell you and the regulators.

The short version

• We have a written plan: contain, assess, fix, notify, and learn. (Full text, section 2)
• If a breach affects your workspace data, we tell you without undue delay, and within 48 hours of confirming it. (Section 3)
• Where we are the controller, we tell regulators within the deadline the law sets, for example 72 hours in the EU and UK, and 3 days in Singapore. (Section 4)
• We tell affected people directly when the law requires it, or when they need to act to protect themselves. (Section 5)
• We record every incident, even small ones, and publish a summary of significant ones on our change log. (Section 6)

Full text

1. Definitions

An "incident" is any event that threatens the confidentiality, integrity, or availability of qypu or data in it. A "personal data breach" is an incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

2. Our response steps

1. Detect and record. Anyone at qypu who suspects an incident reports it to the incident lead at once. We open a record with times.
2. Contain. Revoke tokens, rotate secrets, block access, or pause publishing as needed.
3. Assess. Find what happened, which data and people are affected, and the likely risk to them.
4. Notify. Follow sections 3 to 5.
5. Fix and recover. Remove the cause and restore service.
6. Learn. Write a short review within 10 working days, with actions and owners.

3. Telling customers

Where a personal data breach affects Customer Personal Data, we notify the workspace owner without undue delay, and within 48 hours after we confirm it, with the information listed in the DPA section 7.2. We will help you meet your own notification duties.

4. Telling regulators (where we are the controller)

5. Telling affected people

We tell affected people directly, in plain language, when the law requires it or when they can take steps to protect themselves. We say what happened, what data was involved, what we are doing, and what they can do.

6. Platforms

If an incident affects data received from a platform, we notify the platform as its terms require (for example, Meta requires prompt notice of a security incident affecting platform data).

7. Transparency

We publish a short summary of significant incidents on the trust change log once it is safe to do so.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Accessibility Statement

Version 0.1.0 · effective: DRAFT

In one line: We aim for qypu to meet WCAG 2.2 level AA. We have not had it independently tested yet. Tell us about any barrier and we will help.

The short version

• Our target is the Web Content Accessibility Guidelines (WCAG) 2.2, level AA. (Full text, section 1)
• We have not had an independent audit yet, so we do not claim to meet it. (Section 2)
• Known issues are listed below, with what we are doing about them. (Section 3)
• Tell us about any barrier at [CONTACT EMAIL]. We reply within 5 working days and can provide content in another format. (Section 4)

Full text

1. Our target

We aim for qypu.ai, app.qypu.ai, and our documents to conform to WCAG 2.2 level AA.

2. Current status

Partially conformant (self-assessed, not independently tested). Our design system uses colour contrast that meets AA, visible focus outlines, reduced-motion support, and status words as well as colours.

3. Known issues

• Some animated illustrations on the home page may be hard to follow with a screen reader. They have text alternatives; we are reviewing them.
• Policy PDFs are generated from web pages and may not be fully tagged. The web version is the accessible version.
• The post editor has not been tested with all screen readers.

4. Feedback and alternatives

Email [CONTACT EMAIL] with the page and the barrier. We reply within 5 working days. If you cannot use part of qypu, we will help you do the task another way.

5. Enforcement

If you are not happy with our response, you can contact the equality or accessibility body in your country.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Children and Minors

Version 0.1.0 · effective: DRAFT

In one line: qypu is for adults running businesses. We do not target children, and posts may show a child only with a parent's or guardian's written consent.

The short version

• Only adults (18 or over) may use qypu. (Full text, section 1)
• We do not knowingly collect data from children, and we do not target content at under-16s. (Section 2)
• A post may show a real child only with written consent from a parent or guardian, and never with their full name, school, or location. (Section 3)
• We never generate realistic images of children, and never sexual or harmful content involving minors. (Section 4)
• If you think we hold a child's data by mistake, tell us and we will delete it. (Section 5)

Full text

1. Adults only

Authorised Users must be at least 18 years old.

2. No targeting of children

2.1 qypu is not directed at children. We do not set out to collect personal information from children under 13 (US COPPA), or from children under the age of digital consent in their country.

2.2 Customers must not use qypu to create content aimed at, or to collect data from, people under 16, and must use platform audience settings to exclude under-18s where the content is age-restricted (for example, alcohol).

3. Real children in content

3.1 A business may include a real child in a photo or video (for example, at a family event) only if:

• a parent or guardian has given written consent for that specific use, recorded in qypu;
• the post does not show the child's full name, school, home, or real-time location; and
• the content is not sexual, humiliating, or harmful.

3.2 The customer must remove the content promptly if consent is withdrawn.

4. AI and minors

4.1 We do not generate realistic images, video, or voices of children.

4.2 Our Checks block any content that sexualises or endangers minors. We report child sexual abuse material to the relevant authorities (for example, NCMEC in the US, the IWF in the UK, and the eSafety Commissioner in Australia) and preserve evidence as the law requires.

5. If we hold a child's data

Email [CONTACT EMAIL]. We will delete it promptly, unless the law requires us to keep it.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Voice and Likeness Consent

Version 0.1.0 · effective: DRAFT

In one line: We use a real person's voice or face in AI content only with their informed, written, and revocable consent. Synthetic voices are labelled.

The short version

• Voice and likeness features are Planned. This policy applies from the day they launch. (Full text, section 1)
• We never clone or imitate a real person's voice, face, or body without their written consent. (Section 2)
• Consent must be specific: who, what, where, how long, and whether they are paid. (Section 3)
• The person can withdraw consent at any time. We then stop new uses and delete their voice or likeness data within 30 days. (Section 4)
• Content with a synthetic voice or face is labelled as AI. (Section 5)
• We never imitate celebrities, public figures, or competitors. (Section 6)

Full text

1. Scope

This policy covers any feature that records, clones, imitates, or generates a real person's voice, face, body, or other recognisable likeness ("Likeness"), including through providers such as ElevenLabs (if adopted). These features are Planned.

2. Consent first

We create or use a Likeness only after the person (the "Talent") has given informed, written consent through qypu's consent form, and the customer has confirmed it. Staff members must be free to say no without any effect on their job; customers must not make consent a condition of employment.

3. What consent must cover

• The Talent's identity, verified by a short live recording or another check.
• The business and channels where the Likeness may be used.
• The types of content allowed (for example, voice-overs for product videos) and any topics excluded.
• The duration of the licence.
• Any payment, or a statement that there is none.
• How to withdraw consent.

4. Withdrawal

4.1 The Talent may withdraw consent at any time by emailing [CONTACT EMAIL] or through the customer.

4.2 We stop generating new content within 1 working day and delete the Likeness data (recordings, voice models, and reference images) within 30 days. Published content remains the customer's responsibility; we help the customer take it down where the licence requires.

5. Labelling

Content that uses a synthetic voice or face is labelled as AI-generated, following the AI Transparency and Disclosure Policy, even when the Talent consented.

6. Prohibited uses

• Imitating any public figure, celebrity, politician, or competitor, or anyone who has not consented.
• Using a Likeness in political, sexual, defamatory, or misleading content.
• Using a deceased person's Likeness without the authorisation of their estate where the law requires it.
• Creating a Likeness of a child.

7. Biometric data

Voice recordings may be treated as biometric data in some places. We use them only to produce content for the consenting Talent, never to identify people, and we keep them for no longer than section 4 allows.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Valuation (AVM) Disclaimer

Version 0.1.0 · effective: DRAFT

In one line: Our AVM engine gives an estimated value range with its evidence. It is not a professional appraisal, an offer to buy, or financial advice.

The short version

• The AVM engine (first use: Speedvark, for wine) estimates a value range from market data. (Full text, section 1)
• It is an estimate, not a professional appraisal, an offer, or financial, tax, or insurance advice. (Section 2)
• Every estimate shows a range, the date, the evidence used, and how confident we are. (Section 3)
• A named specialist reviews estimates before they are released, where the service says so. (Section 4)
• Do not rely on an estimate alone for lending, insurance, tax, legal, or estate decisions. (Section 5)

Full text

1. What the AVM does

The automated valuation model ("AVM") engine estimates the likely market value of an item (first: fine wine, under the Speedvark name) using recent sales, auction results, listings, and condition information you provide. AVM features are Planned.

2. What an estimate is not

An AVM estimate is not:

• a formal appraisal or valuation by a qualified or certified appraiser;
• an offer by us or anyone to buy or sell at that price;
• investment, financial, tax, insurance, or legal advice; or
• a statement of authenticity or provenance. We do not inspect items.

3. What every estimate shows

• A value range and a central estimate, with the currency and date.
• The main evidence used, such as comparable sales, with dates and sources where licences allow.
• A confidence level, and the factors that lower it (for example, few comparable sales or unverified condition).
• The inputs you provided.

4. Human review

Where the service says an estimate is "specialist-reviewed", a named specialist has checked the evidence and range before release. Their review is still an estimate.

5. Limits and your responsibility

5.1 Markets move. Prices can differ a lot from an estimate, especially for rare items, damaged items, or items with uncertain provenance.

5.2 Do not use an estimate as the only basis for lending, insurance, tax, probate, legal, or investment decisions. Ask a qualified professional.

5.3 Our liability for estimates is limited as set out in the Terms of Service.

6. Fairness

The AVM values items, not people. It does not use personal characteristics of owners.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Complaints and Contact

Version 0.1.0 · effective: DRAFT

In one line: How to reach us, how we handle complaints and appeals, and where to go if we do not put things right.

The short version

• Email [CONTACT EMAIL] for anything. Put "Complaint" in the subject line if it is a complaint. (Full text, section 1)
• We acknowledge within 2 working days and aim to resolve within 15 working days. (Section 2)
• If we paused your post or account, you can appeal. Someone not involved in the first decision reviews it. (Section 3)
• If you are not satisfied, you can go to a regulator or ombudsman; we list them below. (Section 4)

Full text

1. Contacts

2. How we handle complaints

1. We acknowledge your complaint within 2 working days.
2. A named person handles it and may ask for more information.
3. We aim to give you a full answer within 15 working days. If it will take longer, we tell you why and when to expect it.
4. Our answer explains what we found, what we will do, and how to escalate.

3. Appeals of moderation decisions

If we blocked a draft, paused a channel, or suspended a workspace, reply to our notice or email [CONTACT EMAIL] with "Appeal" in the subject line within 30 days. A different person reviews the decision and replies within 5 working days.

4. Escalation

• Privacy: your data protection authority (see the Privacy Notice annexes).
• Consumer or small-business disputes: your local consumer or small-business ombudsman where one exists (for example, the Australian Small Business and Family Enterprise Ombudsman).
• Courts, as the Terms of Service describe.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Service Levels (draft)

Version 0.1.0 · effective: DRAFT

In one line: Our draft targets for uptime, support response, and publishing. They are aims, not guarantees, until we can measure them reliably.

The short version

• These are draft targets. They are not contractual commitments yet. (Full text, section 1)
• Uptime target: 99.5% a month for app.qypu.ai. (Section 2)
• Support: first reply within 1 working day. (Section 3)
• Signed posts: published within 15 minutes of their scheduled time, unless a platform is down. (Section 4)
• We tell you about planned maintenance at least 48 hours in advance. (Section 5)

Full text

1. Status

These service levels are draft targets. They become commitments only when your order says so, and after we publish 3 months of measured results.

2. Availability

Target: app.qypu.ai available 99.5% of each calendar month, excluding planned maintenance and outages of third-party platforms.

3. Support

Working hours: Monday to Friday, 09:00 to 17:00 [TIME ZONE], excluding public holidays.

4. Publishing

Signed posts are sent to the platform within 15 minutes of the scheduled time. If a platform rejects or delays a post, we tell you and retry where it is safe.

5. Maintenance

We give at least 48 hours' notice of planned maintenance that could affect publishing, on our change log and by email.

6. Service credits

Planned. We will define credits when targets become commitments.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Billing and Refund Basics

Version 0.1.0 · effective: DRAFT

In one line: Clear prices, no hidden fees, cancel any time in two clicks, and fair refunds when we fall short.

The short version

• You see the full price, and whether tax is included, before you pay. (Full text, section 1)
• Plans renew each month (or year) until you cancel. We remind you 7 days before an annual renewal. (Section 2)
• Cancel any time in Settings. You keep access until the end of the period you paid for. (Section 3)
• Refunds: pro-rata for unused prepaid time if we make a material change you reject, or if we end the service without cause. (Section 4)
• Outcome-based pricing, where offered, is set out in writing before work starts. (Section 5)

Full text

1. Prices

Prices are shown on the pricing page and at checkout, in your currency where available, with tax treatment stated. There are no setup fees unless your order says so.

2. Renewal

Monthly and annual plans renew automatically. We email a reminder at least 7 days before an annual renewal, and before any price increase, which we announce at least 30 days in advance.

3. Cancellation

3.1 The owner can cancel in Settings, then Billing, in no more than two clicks after reaching that page. We confirm cancellation by email.

3.2 You keep access until the end of the paid period. We do not charge cancellation fees.

4. Refunds

4.1 We refund unused prepaid fees pro rata if: we make a material change you reject under the Terms; we end the service without cause; or we materially fail to provide the service and do not fix it within 14 days of notice.

4.2 Otherwise, fees for a period already started are not refundable, except where the law gives you a right to a refund.

5. Outcome-based pricing

Where an engine offers pricing based on results (for example, a share of measured savings), the order sets out the baseline, the measurement method, the share, any cap, and how disputes about measurement are settled, before work starts.

6. Failed payments

If a payment fails, we email you and retry. If an undisputed amount is still unpaid 14 days after our reminder, we may suspend the service after a further 7 days' notice. We do not delete data during suspension.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Standard Agreement for Small-Business AI and Managed Services (v0.1 draft)

Version 0.1.0 · effective: DRAFT

In one line: A proposal for a short, open, plain-English standard contract between a small business and any AI or managed-services provider, built like Y Combinator's SAFE: one cover sheet of choices, fixed standard terms, and country modules.

The short version

• Small businesses sign long, one-sided contracts they cannot afford to check. A short public standard would cut cost, build trust, and speed decisions. (Full text, part A)
• Y Combinator's SAFE shows the model: one short document, a few variables, published openly, versioned, with extras in side letters. (Part B)
• Our proposal: a one-page Cover Sheet with about 12 choices, fixed Standard Terms that nobody edits, and a module for each country. (Part C)
• We propose to publish it under Creative Commons Attribution 4.0 (CC BY 4.0), with a rule that only unmodified text may use the standard's name. (Part D)
• Versions are numbered and dated, changes are explained in public, and anyone can comment. (Part E)
• The v0.1 draft is below. It is a starting point for counsel and for comment, not a finished contract. (Part G)

Full text

Part A. Why a standard helps

Cost. A café or a plumber cannot pay a lawyer to read a 30-page agreement for a €50-a-month service. A standard document only needs expert review once, by many people, and then everyone benefits.

Trust. If the terms are public and the same for everyone, the owner knows the provider has not hidden anything special in their copy. Differences live only on the Cover Sheet, where they are easy to compare.

Speed. When both sides know the standard, the only questions are the Cover Sheet choices. A deal can close in minutes, not weeks.

Fair defaults. A standard can set fair defaults for things small businesses rarely negotiate: who signs off on AI output, data export when you leave, and liability that is not one-sided.

Comparability. Owners can compare providers on price and service, not on legal fine print.

Part B. What the SAFE teaches

The SAFE (Simple Agreement for Future Equity) was created at Y Combinator by partner and lawyer Carolynn Levy and announced in December 2013 as a replacement for convertible notes. Lessons we take from it:

1. Short and standard. YC describes it as one short document where usually the only term to negotiate is the valuation cap (ycombinator.com/documents).
2. Published openly, free to use. YC published the standard document for all startups to use, not only its own (YC blog, "Announcing the Safe"; TechCrunch, 6 December 2013).
3. Few variables. Each form differs only by a small number of filled-in terms (valuation cap, discount, or MFN) (ycombinator.com/safe).
4. Extras go in side letters. YC advises keeping the SAFE unmodified and putting agreed extras (for example, pro rata rights) in a separate standard side letter (YC FAQ, ycombinator.com/documents).
5. Versioned, with reasons. In 2018 YC replaced the original "pre-money" SAFE with the "post-money" SAFE and published a user guide explaining what changed and why (Primer for post-money safe v1.1).
6. Local versions, honestly labelled. YC offers versions for Canada, the Cayman Islands, and Singapore, and tells users to consult a lawyer licensed in the relevant country (ycombinator.com/documents).
7. A respected publisher. Adoption followed because YC used it for every company it funded, starting with its Winter 2014 batch (TechCrunch).

What differs for us: a SAFE has two sophisticated parties and one event (conversion). A services agreement runs for years, involves personal data, and often has a small business that the law may treat like a consumer. Our standard must therefore carry more mandatory protections, and more country modules.

Part C. Proposed structure

1. Cover Sheet (variables). One page. The only place the parties make choices.
2. Standard Terms (fixed). About 12 short sections in plain English. Never edited. Incorporated by reference with a version number.
3. Country Modules. Short add-ons that adapt the Standard Terms to mandatory local law (US, Canada, UK, EU, Switzerland, Singapore, Australia, and New Zealand). The Cover Sheet names the module.
4. Engine or Service Schedule. What exactly is provided (for example, "3 social posts a week, signed by the Customer").
5. Standard Side Letters (optional). Outcome pricing, service credits, extra security, or data residency. Each is a fixed text with its own few variables.
6. Data Processing Addendum. A standard DPA, also fixed, with the transfer clauses for each region.

Part D. Licence for publication

Recommendation: publish the text under CC BY 4.0, which lets anyone use and adapt it with attribution. Add a short naming rule: only unmodified Standard Terms may be described as "the Standard Agreement vX.Y". Modified versions must drop the name and say they are modified.

Why not CC BY-ND (no derivatives)? It protects the standard but blocks local lawyers from improving it. The naming rule protects the standard while allowing improvement. YC's own SAFE forms carry a Creative Commons licence; counsel should confirm its exact terms before we cite it as a precedent.

The name itself should be checked for trademark conflicts before launch.

Part E. Governance and versioning

• Semantic versions. v0.x drafts; v1.0 first recommended version. Minor versions (1.1) clarify; major versions (2.0) change rights or duties.
• Public change log with the reason for every change, as the SAFE primer did.
• Open comment on each draft for at least 60 days, through a public repository and email.
• Advisory panel: at least one practising lawyer per country module, two small-business owners, a consumer or small-business advocate, and two providers other than qypu. qypu should not hold a majority.
• Stewardship: start at qypu; move to a neutral body (for example, a foundation or an industry association) once at least 3 other providers adopt it.
• No forced upgrades. A signed agreement stays on its version until both parties agree to move.

Part F. Risks

Part G. v0.1 draft — DRAFT, requires review by qualified counsel in each jurisdiction

G1. Cover Sheet

G2. Standard Terms

1. What this is. These Standard Terms, the Cover Sheet, the Service Schedule, the Country Module, any Side Letters, and the DPA form one agreement. If they conflict, this order applies: Country Module, Cover Sheet, Side Letters, DPA (for personal data), Standard Terms, Service Schedule.

2. The service. The Provider delivers the service in the Service Schedule with reasonable skill and care, and tells the Customer promptly about anything that will stop it doing so.

3. Who decides (editorial responsibility). The Customer decides what is published or acted on in its name. The Provider must not publish, send, pay, or commit on the Customer's behalf without the sign-off named in Cover Sheet item 5. The Provider keeps a record of each sign-off.

4. AI use and disclosure. The Provider tells the Customer which parts of the service use AI and which AI providers process Customer data. The Provider labels AI-generated content where the law or the platform requires, and never removes provenance marks. The Provider does not use Customer data to train AI models unless the Customer opts in on a separate signed form.

5. Customer data. The Customer owns its data and content. The Provider uses them only to provide the service. The DPA applies to personal data. The Provider keeps a public list of subprocessors and gives 30 days' notice of changes.

6. Security. The Provider keeps security measures appropriate to the risk, publishes a plain description of them labelled "in place" or "planned", and tells the Customer about a breach affecting Customer data without undue delay and within 72 hours of confirming it.

7. Fees. The Customer pays the fees on the Cover Sheet. The Provider may raise fees only with 60 days' notice, and the Customer may end the agreement before the increase applies.

8. Accounts and access. Accounts, domains, and channels belong to the Customer and stay in the Customer's name. The Provider uses delegated access (such as OAuth or user roles), never the Customer's personal passwords, unless the Customer agrees in writing.

9. Liability. Neither party limits liability: for fraud; for death or personal injury caused by negligence; or for anything else the law does not allow to be limited. Otherwise each party's total liability in any 12 months is limited to the cap on the Cover Sheet, and neither is liable for indirect loss or lost profits.

10. Ending the agreement. Either party may end the agreement with the notice on the Cover Sheet, or at once if the other materially breaches and does not fix it within 14 days of notice.

11. Exit and data portability. On any ending, the Provider: gives the Customer at least 30 days to export all Customer data in a common, machine-readable format, free of charge; hands back control of every account and channel; helps for up to 30 days with a reasonable handover to a new provider at no more than cost; then deletes Customer data and confirms in writing, except for data the law requires it to keep.

12. Changes and general. These Standard Terms change only by a new version. Signed agreements stay on their version until both parties agree in writing. Notices are by email to the addresses on the Cover Sheet. Neither party may transfer the agreement without consent, except with a sale of its whole business.

G3. Country Modules (outline)

• US: governing law of the Customer's state by default; CCPA service-provider terms in the DPA; state auto-renewal rules for renewals; no class-action waiver by default.
• Canada: law of the Customer's province; PIPEDA and provincial privacy terms; Quebec Law 25 transfer assessment; French-language version available for Quebec customers (Charter of the French Language).
• UK: law of England and Wales (or Scotland or Northern Ireland, at the Customer's choice); UK GDPR and the IDTA or UK Addendum; terms reviewed for reasonableness under the Unfair Contract Terms Act 1977.
• EU: law of the Customer's member state; GDPR and SCCs; EU Data Act switching terms (notice, export, and charges); AI Act Art. 50 disclosure duties allocated.
• Switzerland: Swiss law; revFADP; Swiss SCC amendments.
• Singapore: Singapore law; PDPA terms, including 3-day breach notice support.
• Australia: law of the Customer's state or territory; Australian Consumer Law guarantees preserved; unfair contract terms review for small-business contracts; Privacy Act APP 8.
• New Zealand: NZ law; Consumer Guarantees Act and Fair Trading Act preserved where they apply; Privacy Act IPP 12.

G4. Standard Side Letters (outline)

• A. Outcome pricing: baseline, measurement method, share, cap, measurement period, audit right, and dispute resolution by an agreed independent expert.
• B. Service credits: targets and credits as a percentage of monthly fees.
• C. Data residency: named regions and the consequences of change.

Change log

• 2026-10-10 · 0.1.0 · First public draft for comment and counsel review.

Modern Slavery and Supply Chain

Version 0.1.0 · effective: DRAFT

In one line: The law does not yet require us to publish a modern slavery statement. We still set basic standards for the suppliers we use.

The short version

• UK, Australian, and Canadian modern slavery reporting laws apply only above size thresholds we do not meet. (Full text, section 1)
• We publish this note voluntarily, and we will publish a full statement when the law requires it. (Section 2)
• Our main suppliers are cloud and AI companies. We check that they publish their own statements or ethics policies. (Section 3)

Full text

1. Legal position

• UK: section 54 of the Modern Slavery Act 2015 applies to organisations with turnover of £36 million or more. We are below it.
• Australia: the Modern Slavery Act 2018 (Cth) applies to entities with consolidated revenue of A$100 million or more. We are below it.
• Canada: the Fighting Against Forced Labour and Child Labour in Supply Chains Act applies to entities that meet size tests (for example, at least 2 of: C$20 million in assets, C$40 million in revenue, or 250 employees) or are listed in Canada. We are below them.
• EU: the Corporate Sustainability Due Diligence Directive applies to very large companies only.

2. Our commitment

We do not tolerate forced labour, child labour, or human trafficking in our business or supply chain. We will publish a full statement when any of the laws above applies to us.

3. Suppliers

Our suppliers are listed on the Subprocessors page. Before we add a supplier, we check that it publishes a modern slavery statement or a supplier code of conduct. Where we use human data labelling or review services, we will require fair pay and working conditions.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Government and Law Enforcement Requests

Version 0.1.0 · effective: DRAFT

In one line: We hand over customer data only when the law truly requires it, we push back on overbroad requests, and we tell you unless we are legally barred.

The short version

• We require valid legal process, such as a court order or warrant, before we disclose customer data. (Full text, section 1)
• We check every request and challenge ones that are unclear, overbroad, or from the wrong place. (Section 2)
• We tell the customer before we disclose, unless the law forbids it or someone's life is at risk. (Section 3)
• We will publish a yearly count of requests. So far we have received none. (Section 4)

Full text

1. Valid process only

We disclose customer data to a government body only if the request is in writing, is legally valid and binding on us, and is limited to specific data. Emergency requests involving an imminent risk of death or serious injury are considered case by case.

2. Review and challenge

We review each request with counsel. We seek to narrow or challenge requests that are overbroad, lack a legal basis, or conflict with the law of the country where the person is protected (for example, GDPR Article 48 on foreign court orders).

3. Notice

We notify the affected customer before disclosure, so it can seek a remedy, unless the law forbids notice or notice would create a risk of harm. If a ban on notice ends, we notify then.

4. Transparency

We will publish the number and type of requests received each year on the trust change log. As of 10 October 2026 we have received no requests.

Change log

• 2026-10-10 · 0.1.0 · First draft.

Who Does What

Version 0.1.0 · effective: DRAFT

In one line: Keeping your business safe online is a shared job. This page shows clearly what qypu does, what you do, and what the platforms and our providers do.

The short version

• qypu drafts, checks, protects your data, and publishes only what you sign. (Full text, section 1)
• You decide what is true, who can sign, and what gets published. You keep your own sign-in safe. (Section 2)
• Platforms (Meta, TikTok, LinkedIn, and YouTube) run their own services and rules. (Section 3)
• Our providers run the hosting, database, and AI models under contract with us. (Section 4)
• If something goes wrong, the table shows who acts first. (Section 5)

Full text

1. What qypu does

• Builds your Brand Kit from your answers and keeps it where you can edit it.
• Drafts content within your hard facts, never-say list, and licence level.
• Runs Checks and shows you every flag.
• Publishes only posts you have signed, on channels you connected.
• Labels AI content and keeps provenance marks.
• Encrypts access tokens and deletes them when you disconnect.
• Gives AI steps only the access their task needs.
• Monitors the service and tells you about incidents that affect you.

2. What you do

• Keep your hard facts true and up to date.
• Choose your signers carefully, and remove people who leave.
• Read every post before you sign it.
• Get consent from anyone who appears in your content.
• Keep your own email and platform accounts secure, with multi-factor authentication.
• Tell your staff how qypu is used in your business.

3. What the platforms do

• Run the social networks and decide what their rules allow.
• Show AI labels to your audience.
• Control their own security, outages, and data handling, under their own privacy policies.

4. What our providers do

• Host the app (Vercel), protect the network edge (Cloudflare), store data (Supabase), sign you in (WorkOS), and run AI models (for example, Anthropic). The full list is on the Subprocessors page.
• Each is bound by contract to protect your data and use it only for qypu.

5. When something goes wrong

Change log

• 2026-10-10 · 0.1.0 · First version. Adapted from the "shared responsibility" idea common in cloud security, written for small businesses.

Subprocessors

Version 0.1.0 · effective: DRAFT

In one line: The companies that process customer data for us, what they do, where, and what data they touch. We give 30 days' notice before adding one.

The short version

• This list names every company that processes your workspace data for us. (Full text, section 1)
• Each one is under a written contract with data protection terms. (Section 2)
• We give at least 30 days' notice before a new one starts handling your data. You may object. (Section 3)
• Rows marked "To confirm" are in our code but not yet confirmed as used for customer data. We will confirm or remove them before launch. (Section 1)
• A machine-readable copy is at /trust/subprocessors.json. (Section 4)

Full text

1. Current list

The table on this page is generated from /trust/subprocessors.json, so both always match.

2. Contracts

Each subprocessor has signed, or accepted, a data processing agreement with terms at least as protective as our DPA, including international transfer safeguards where needed. AI providers are contractually barred from training on our data.

3. Changes

We update this page and the JSON file at least 30 days before a new subprocessor starts handling customer data, and record the change in the history below. To get an email, write to [CONTACT EMAIL] with the subject "Subscribe: subprocessor changes". You may object, giving data protection reasons, during those 30 days (see DPA section 6).

4. Machine-readable file

/trust/subprocessors.json uses a simple schema: name, legal entity, purpose, data categories, location, transfer mechanism, retention, status, and date added.

Change log

• 2026-10-10 · 0.1.0 · First list, built from the current architecture and code.

Certifications

Version 0.1.0 · effective: DRAFT

In one line: We hold no security or privacy certifications yet. This page says what we hold, what we plan, in what order, and why.

The short version

• We hold no certifications or audit reports today. We will not claim one until an independent auditor issues it. (Full text, section 1)
• Our first steps are the UK Cyber Essentials badge and a public cloud-security questionnaire. (Section 2)
• Next, an independent auditor will check us for a SOC 2 report, and later for ISO/IEC 27001. (Section 2)
• No one certifies a website as "post-quantum ready." We follow the US standards body NIST's post-quantum methods where our providers support them. (Section 3)
• Our providers hold their own certifications. That helps, but it does not certify qypu. (Section 4)

Full text

1. Where we are today

qypu is a new, small service. We hold no security, privacy, or AI certification, and no audit report. Each item below is labelled In place or Planned. Planned means we intend to do it; it is not a promise of a date.

2. Our plan, in order

• Planned: UK Cyber Essentials. A UK government-backed check of five basic controls: firewalls, safe settings, who has access, malware protection, and updates.
• Planned: A public answer sheet to the Cloud Security Alliance questionnaire (STAR Level 1). It answers the questions IT reviewers ask most.
• Planned: UK Cyber Essentials Plus. The same five controls, tested hands-on by an assessor.
• Planned: A SOC 2 report from an independent accounting firm. It first checks that our controls are well designed, then that they worked over several months. We plan to cover security and confidentiality first, and privacy later.
• Planned: ISO/IEC 27001, the international standard for managing information security.
• Planned, later: privacy and AI standards such as ISO/IEC 27701 and ISO/IEC 42001, and the EU Cloud Code of Conduct.

When an audit starts, we will say so here. When a report or certificate is issued, we will show its date, its scope, and how to request a copy.

3. Post-quantum

Future quantum computers may break some of today's encryption. There is no recognised certification that a website or service is "post-quantum ready," so we do not claim one. In August 2024, NIST published its first post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). We follow them where our providers support them.

• In place: Connections through Cloudflare can use post-quantum key exchange when your browser supports it.
• Planned: Post-quantum protection for long-lived secrets, such as account tokens and signed approvals.

4. Our providers

Our hosting, database, network, and AI providers hold their own certifications, such as SOC 2 and ISO/IEC 27001. You can find them on our subprocessors page. Their certificates cover their services, not ours.

5. Rules we follow without a certificate

Some rules have no certificate. We follow them anyway: GDPR and UK GDPR for personal data, and the EU AI Act's rule that AI-made content must be labelled. See AI transparency and security.

Change log

• 2026-10-10 · 0.1.0 · First version.