Six things cross. Four things never do.
The integration layer between this platform and the game is deliberately narrow, explicitly versioned, and defined by its refusals rather than by its capabilities. Most integration failures are failures of appetite: two systems that could share everything eventually do.
The whole contract, in two columns.
What crosses
- An SSO token, so that a member does not have two accounts
- A membership tier — Loitering, Mucking In, Ploughing On, Landlording — as a single enumerated value
- An age-verified boolean. True or false, and nothing about how it was established
- Achievement events, one way, from the game to the platform
- A commerce bridge for non-alcohol products only, which passes a basket and never a customer
- Shared parish membership, as a parish identifier and nothing else
What must never cross
- A raw date of birth. Ever, in either direction, for any reason
- Payment-card data of any kind, tokenised or otherwise
- Alcohol purchase history, or any signal derived from it
- A child’s precise location, at any resolution finer than a parish
- A child’s behavioural profile, play pattern, session record or engagement score
- Free text written by any user, in either direction
- Anything that could reconstruct one of the above by joining two permitted fields
The six fields, specified.
Identity and entitlement
- SSO token
- Short-lived, scoped, single-purposeEstablishes that this is the same person. Carries no attributes beyond a subject identifier.
- Membership tier
- An enumerated value, four possibilitiesNot a spend figure, not a join date, not a history. One word.
- Age-verified boolean
- True or falseThe game learns that the person is over the threshold. It never learns the birth date, the method, or the margin.
Events and commerce
- Achievement events
- Game to platform, one wayA stable event name and a timestamp. No score, no rank, no play pattern.
- Commerce bridge
- Non-alcohol products onlyThe game hands a basket to the shop. The shop never hands a customer to the game.
- Parish membership
- A parish identifierTwelve possible values. Not a postcode, not a coordinate, not a distance.
How it is versioned
- Version in the path
- /v1/, /v2/Not a header, not a query parameter, and not negotiated. A version is a different URL.
- Breaking changes
- A new version onlyThe old one runs for a minimum of twelve months alongside it.
- Adding a field
- Requires a named approver and a DPIA reviewBecause the failure mode of an integration layer is that it grows one convenient field at a time.
- Removing a field
- Allowed at any timeDeliberately asymmetric. Taking things out is easy and putting things in is hard.
Every one of the six is the narrowest possible representation of the thing it carries. An age-verified boolean instead of a birth date. A parish instead of a postcode. A tier instead of a spend history.
Why each of the four refusals is absolute.
-
A raw date of birth.
The game needs to know whether somebody is over an age threshold. It does not need to know their birthday, and the difference between those two statements is the difference between a boolean and a permanent piece of identifying personal data about, in many cases, a child.
Under the Children’s Code, data minimisation is a design requirement rather than a policy aspiration. Passing a birth date where a boolean would do is the clearest possible failure of it.
A boolean answers the question. A birth date answers a question nobody asked.
-
Payment-card data.
There is no version of this integration where card data needs to move between a game and a farm shop. The commerce bridge hands a basket to a checkout that already exists and already handles payment, and the game never sees a card.
This is also a scope decision about PCI DSS. A game that never touches card data has a dramatically smaller compliance surface than one that touches it once, and there is no benefit on the other side of that trade.
The game hands over a basket. It never handles a card.
-
Alcohol purchase history.
If the game knew that a player had bought beer, the game would eventually use it — to segment, to target, to personalise. And the moment a game likely to be accessed by children personalises anything on the basis of alcohol purchase, CAP rule 18.15 stops being a question about creative and starts being a question about the product.
So the field does not exist. Not restricted, not gated, not available to authorised callers. Absent.
A field that does not exist cannot be misused by somebody in a hurry.
-
A child’s location or behavioural profile.
A parish is twelve possible values covering the whole country. That is enough for the social layer and it is not enough to find anybody. Nothing finer crosses in either direction, at any resolution, for any purpose.
The behavioural half is the less obvious one and the more important. Session lengths, play patterns, response to prompts and engagement scores about a child are exactly the data the Children’s Code was written about, and the correct amount of it to move between two systems is none.
A parish is not a location. An engagement score about a child is not a metric.
What happens when somebody asks for a seventh field.
| Request | Answer | Why |
|---|---|---|
| "Can we pass the player’s email for the newsletter?" | No | The platform already has it. The game does not need it, and consent given in one place is not consent given in the other |
| "Can we pass lifetime spend so we can thank big spenders?" | No | That is a segmentation field wearing a compliment |
| "Can we pass session frequency so the shop can time an email?" | No | That is a behavioural profile, and a meaningful share of the profiles would be children’s |
| "Can we pass the postcode for delivery?" | No | The checkout collects it at the point of delivery. The game never holds it |
| "Can we pass an alcohol-eligible flag?" | No | It is the alcohol history in one bit, and one bit is enough to segment on |
| "Can we add a field just for internal analytics?" | No | Internal analytics is where every integration layer goes to become a data lake |
The contract, questioned.
Because two systems that can share everything eventually do, one convenient field at a time, and the end state is a behavioural profile of a child sitting in a game database because somebody needed it for a dashboard.
It does not, from the game. The commerce bridge hands a basket to a checkout the customer completes themselves, with their own account, on the platform that already has their details.
It goes through a named approver and a DPIA review, and the answer is usually no. Removing a field needs no approval at all, which is the asymmetry the whole contract is built on.
And the reason there is no beer in any of it.
CAP rule 18.15, the twenty-five per cent threshold, and why a zero per cent version does not help.
Elsewhere on the estate.
/estate/the-money/
/estate/recording/
/estate/sitemap/
