Platform annexes

What a platform annex is

An agent we build runs inside a system a business already uses. Six of those systems come up often enough that each one gets its own document here.

A Platform annex is a factual description of one platform: what its APIs expose to an app, whose personal data that reaches, how a merchant installs and authorises an app, what happens to access and data when the app is removed, and whether the platform runs a compliance mechanism of its own. It is a description, not a contract, and it does not change your agreement with that platform.

These pages exist because the same facts kept being restated. Every app privacy policy was repeating what Shopify exposes, or what a WordPress plugin can reach, and repeated text drifts apart. Now each platform is described once, here, and the app policies point at it.

The six annexes

How inheritance works

There are two layers, and each answers a different question.

• The platform annex answers "what could an app reach here at all?" It describes the outer limit: everything the platform makes available to an app that asks for it, whether or not any app of ours asks.
• The app privacy policy, at /legal/apps/, answers "what does this particular app actually hold?" It names the permissions that app was granted, the records it touches, where the data goes and how long it is kept.

Read together, three rules apply:

• An app never holds more than its platform annex describes. It normally holds far less, because we ask for the narrowest permission a task needs.
• Where an app policy and its platform annex differ about what that app does, the app policy governs. The annex describes the platform, not the app.
• If a fact about a platform is wrong here, it is wrong everywhere. That is the point. Correcting it once corrects every app policy that inherits it, and the correction is recorded in that annex's version history.

Two definitions carry across all of them, so they are worth stating on this page too. For End Customer Data that an Agent reads or writes on your systems, you are the controller and we are the processor. For Service Data, the data we hold to run our own business, we are the controller. The full processor terms are in the data processing addendum.

What every annex covers

All six use the same section headings, in the same order, with the same anchors. You can compare two platforms by opening the same section on both.

• What this platform exposes to an app. A table of the resources and permissions an app can request, what each one contains, and whether it includes end-customer personal data. The resource names are the ones the platform itself uses.
• Personal data, and whose it is. Which people appear in the data, and the fact that they are the merchant's end customers rather than ours.
• Install and authorisation. How an app is installed, what the merchant is shown, and what approving that screen actually agrees to.
• Uninstall and deletion. What happens to access, what happens to data the app already copied, what stays in the merchant's own store, and what the platform requires an app to do.
• The platform's compliance mechanism. Where the platform runs one. Shopify does, and its three mandatory compliance webhooks are described in full. For the others, this section says what has to be checked rather than assuming an equivalent exists.
• Where the platform's policies govern. Your agreement with the platform, the platform's own cookies inside its admin, payments, and the other places where nothing we publish applies.

What an annex does not cover

• What one app holds. That is the app's own policy at /legal/apps/.
• Our own handling of personal data. That is the privacy policy.
• Processor terms, retention and breach notification. Those are in the data processing addendum.
• What reaches a model provider. That is AI and your data, and the list of third parties is at sub-processors.
• Your agreement with the platform. We are not a party to it and we do not restate it.
• Commercial terms. Nothing on these pages sets a price, a notice period, a liability position or a service level.

Confidence and verification

These annexes make factual claims about companies we do not control, and platform requirements change on the platform's schedule. So there is a rule we hold ourselves to on these six pages, and it is stricter than the rest of this site.

• A requirement is stated as fact only where it is stable and widely known. Shopify's three mandatory compliance webhook topics are the clearest example.
• Anything else, an exact permission name, a retention window, a deadline to respond to a callback, or whether a mechanism exists at all, is marked {{VERIFY: what needs checking, and against which documentation}} until someone has read it off the platform's current documentation.
• We would rather show you a gap than a confident guess. There are many verification markers across these six pages, and that is deliberate. A marked gap gets filled. A wrong assertion that reads well gets believed.
• Values only Rahul can supply, such as a retention period or any commercial term, are marked {{TODO: what is missing}} and are not invented either.

If you find a statement on any of these pages that no longer matches what the platform publishes, tell us at hello@aispeedforce.com. We will correct it and record the change in that annex's version history.

Related documents

• App policies. The per-app privacy policies that inherit these annexes.
• Privacy policy. Personal data we handle on this website and in agency work.
• Data processing addendum. The processor terms behind the roles described here.
• AI and your data. What reaches a model provider, and on what terms.
• Sub-processors. Every third party that may process data on our behalf.
• Security. How platform credentials are held.
• All legal documents.
• Platforms. What we actually build on each of the six.

Changes to these annexes

We may update these documents. When we do, we change the "Last updated" date on the page that changed and add a row to its version history. Section anchors are stable and we do not rename them, so a link to a section keeps working. Each annex carries its own version history, and this index carries the history of the set.

Version history