Platform terms changes: a register with an owner and a route

Most teams find out that a platform rule changed by breaking it.

A change that nobody owns is noticed and then dropped. The fix is running a small register, where each change arrives as a record with one named owner and a route to the people whose work it touches.

What to take away

One owner per entry

Give every change one owner, even when several teams will do the work. The owner opens the register entry, chases the others and records the outcome. Without that name, an entry is a reading list and nobody is accountable for acting on it.

Six fields is the working size. Fewer and it is a bookmark, more and nobody fills it in. The two that get dropped first are the last two, and dropping them turns the register into a reading list.

Route each change to the desk it touches

A change reaches the register through one person but has to reach the people whose work it touches, which is rarely the same person. Decide the route before the first change arrives, so that routing a notice takes a minute and not a meeting.

A deprecation is handled by product teams and often missed entirely by whoever owns policy, even though the operational damage is larger. Commercial terms sit in the agreement rather than in the content policies, and almost nobody re-reads that document.

Where a change alters what colleagues may do, it also has to reach the internal document that tells them, or the two will disagree. A review rule, a named owner and an escalation path belong in the internal policy skeleton.

Where it alters what a service will permit, the rule has to be read against the agreements above it. That is a separate step from routing, and the entry only needs to point to it. Worked situations are in terms in practice.

The owner's three questions

Ask three questions, in this order, when a change reaches the owner. Does it reach us at all, does anything we do now become non-compliant, and by when. Each answer either closes the entry or moves it toward action.

The first question is scope: which surface, which account type, which market. Most changes fail it, and answering it first stops the register filling up with other people's problems. Where a change exists because an obligation was imposed on the service, scope has a second layer.

The EU Digital Services Act applies to services within its own scope, and a service's implementation is frequently wider than the obligation. The European Union sets the regime out at its page on rules for online services.

The second question is the only one that generates work, so name the specific thing that becomes non-compliant, not the general area. The third takes its date from the notice, not from the coverage. If there is no date, the change is already in force and you should treat it that way.

Anything that survives all three gets a due date. Anything that does not gets a line saying it was considered and why it was closed. That closing line is worth writing: the same change will be raised again by someone else, and answering it twice is a waste.

When no document tells the owner

Some changes arrive with no document at all: a threshold moves, a classifier is retrained, a category gets a sweep. The owner learns of them through account outcomes, so the desk that sees those outcomes needs a standing route to the register.

Save a dated copy of each policy your work depends on, at the moment you make a decision that relies on it. When you suspect something moved, compare the current page against that copy rather than against your memory. The value is in having the earlier file, not in the tool.

Public rules behave differently, because official publication systems keep dated, permanent versions: GovInfo's account of what the daily Federal Register contains describes one such system. Services run none.

For each affected item, record the date, the account or asset, the action taken, the rule page as it read that day, and the appeal outcome. One entry proves little. A dozen over three months show whether a threshold moved or the run of losses was chance.

Where a service runs a developer or partner channel, watch it even if you are not a developer. It tends to be earlier, more specific and more precisely dated than the consumer announcement. For how to version the record itself, see a verifiable policy record.

Triggers that put a change on the owner's desk today

Read the register once a quarter, and re-read the policies your work depends on twice a year. A quarterly pass suits announced changes, which arrive with dates and usually with time to spare. Deciding which terms rules apply to you is a separate exercise from this schedule.

Three events jump that schedule:

Treat that last one as a mandatory read. An action is often the first evidence that something moved.

Common questions

Who should own a change that touches several teams?

One named person owns the entry, even when several teams do the work. The others are told, and the owner records the action-by date or the line saying why the entry was closed.

What if the notice gives no date?

Treat the change as already in force. Take any date from the notice, not from the coverage, and plan from there.

Is a summary from a newsletter good enough to act on?

It is good enough to open the register entry. Take the action decision from the service's own page, because summaries routinely describe another market's version.

We missed a change and were actioned for it. Does that help an appeal?

Only if you can show what the rule said when you acted, which means having kept a copy. Not knowing about a change is not usually a defense anywhere.