Most content platforms treat the catalogue as a list of things you have. That is the wrong starting point for media. The catalogue is a list of things you are permitted to show, to certain people, in certain places, for a certain period, on certain devices, sometimes with conditions about what may appear alongside them.
The permission is the asset. The file is just a file.
When a system is built around files first, it can look healthy for a long time. Then a licence lapses. The platform carries on serving the content because, technically, nothing broke. That smooth failure is the expensive part.
Rights belong in the data model
The common shortcut is a start date and an end date on the content record. It survives a demo because it is easy to explain and easy to build. It collapses when it touches any real deal, because real rights are multi-dimensional and frequently overlapping.
The same title can have several different permissions at once. Those permissions can differ by territory, usage, time, device and commercial condition.
A real rights deal may include these separate dimensions:
- Streaming in one territory.
- Download in another.
- Neither in a third.
- A different window for streaming and download.
- A holdback during a theatrical or broadcast window.
- A device restriction.
- A concurrent stream limit.
- A requirement that a particular logo appears.
Two overlapping deals may also apply to the same title, with different terms. In that case, the system has to know which deal it is using. That decision determines who gets paid.
Modelling all of that as dates on a title guarantees that you will eventually be wrong in a way that costs money.
A rights grant should be its own record
We build rights as grants. A rights grant is its own entity, meaning its own record in the system rather than a field attached to a title.
That grant references the content, the set of territories, the set of usage types, the window, the set of conditions and the contract it came from. Availability for a given user at a given moment is then computed. The system looks at who the user is, where they are, what device they are on and what time it is. It then checks which grants apply, and whether at least one grant permits the use.
Computed availability costs more than a boolean on a row, a simple yes/no value stored in the database. It is also the only version that is defensible.
This model gives you something else that matters: the ability to answer why. When somebody asks why a title is not showing in Ireland, the system can point to the grant that would have covered it and explain why that grant does not apply. Without that, an engineer has to work backwards through a chain of flags.
Expiry should be planned before it happens
The failure everybody has heard about is content remaining available after a window closes. Another failure gets less attention: content that never became available because a start date was entered wrong and nobody looked.
Both problems are solved the same way. Treat the rights calendar as something the business operates from every day, with alerts, instead of reference data that sits in the background.
The system should surface these conditions from the rights calendar:
- What expires in the next thirty days.
- What is due to become available and has no file ready.
- What has a grant with no contract attached.
- What is available today under a grant that is due to lapse this week and has no renewal recorded.
None of that is difficult. It usually has not been built because rights are owned by a legal or commercial team, while the platform is owned by engineering. The calendar then lives in a spreadsheet between them.
The contract timezone is the one that matters
Rights windows are contractual, and contracts specify a timezone. That timezone is frequently different from the timezone your servers run in. It is also frequently different from the timezone the viewer is in.
A window that ends on 31 October means something specific. If your system reads that as UTC midnight while the contract meant midnight in Los Angeles, you have eight hours of unlicensed availability every single time.
Eight hours sounds trivial. It is eight hours during which a rights holder’s monitoring can find your content live in a territory where it should not be. The conversation that follows is about whether your controls are adequate at all.
Fast publishing needs pre-approved rights
The second half of this sector works under the opposite pressure. News and live content have to be out in minutes. Every control you add creates friction on the one metric editorial cares about.
The resolution is to make the fast path pre-approved. If a piece of content is being published under a standing grant that already covers this territory, this usage and this window, it goes out with no additional check. The check was done when the grant was signed.
Anything outside that path gets held for a decision. Most content is inside it, so most publishing is unimpeded. The small number of unusual cases get the attention they deserve.
Systems that apply the same review to everything end up with editorial routing around them. That is how you get content published through a side door with no rights record at all.
Takedown has to move faster than publishing
Any platform will eventually need to remove something quickly. The reason may be a legal complaint, a rights dispute, an error or a court order.
The time from decision to unavailable is a number worth knowing. Most organisations do not know it.
The traps are caches and clients. Content removed from the origin may sit in an edge cache for hours. An edge cache is a copy held closer to viewers so playback is faster. An application that fetched a playback manifest may hold it. A downloaded file on a device may play indefinitely unless the licence is checked.
If your takedown story stops at the database, it is not a takedown story.
We build and rehearse this path, including cache invalidation and licence revocation for offline downloads, and we time it. Knowing the number is worth more than any assurance in a policy document.
Rights reporting is where the money is
Rights are also a payment problem. They determine who gets paid what. The reporting obligation is usually contractual and specific: views by title, by territory, by window, by usage type, reconciled and delivered monthly.
If availability is computed from grants, reporting falls out of the same model. Every playback can record which grant it was exercised under.
If availability is a flag on a row, the reporting has to be reconstructed afterwards. Playback logs are joined against a rights spreadsheet. That is slow, error prone and impossible to defend when a rights holder disputes the numbers.
Attention changes how the platform has to work
The commercial context behind all of this is that attention is getting harder to hold and more expensive to buy. That has two consequences for how the platform is built.
First, latency to first frame is a business metric in the same way search latency is in travel. People leave.
Second, recommendation and discovery become load-bearing. That means your rights model has to be fast enough to run inside them. A recommender that suggests titles a user cannot watch is worse than no recommender. Filtering after ranking rather than before produces exactly that, with a sparse and disappointing rail.
Contracts usually arrive as PDFs
Everything above assumes that grants exist as structured records. Usually, they arrive as signed PDFs, sometimes scanned. The commercially significant terms may be distributed across a main agreement, two amendments and an email confirming an extension.
Somebody then reads those documents and types the important parts into a system. That transcription step is where most rights errors are actually born.
This is a good use for a model, and it shows the difference between a defined job and a chat window. The task is narrow: given a contract, extract the territories, the usage types, the window, the holdbacks and the reporting obligations, each with a confidence score and a pointer to the clause it came from.
That last part makes the output usable. The model gives a claim with its source attached, rather than an assertion. A commercial person can then verify it in seconds instead of reading forty pages.
The discipline is the same one we apply anywhere a model touches an operational process.
- Build the held-out set first, from contracts a person has already keyed correctly.
- Measure against it on every change.
- Route anything below the confidence threshold to a human rather than guessing.
- Never let the extraction write directly to the live rights model without a person accepting it.
An incorrectly extracted territory is indistinguishable from a correctly extracted one until a rights holder calls.
Geoblocking is weaker than the contract assumes
Territory restrictions are enforced by geolocation. Geolocation is a probabilistic inference dressed up as a fact.
IP databases lag reality by weeks. Mobile carriers route traffic through gateways in other countries. Corporate networks egress from headquarters. A meaningful proportion of viewers are deliberately using a VPN, which the contract will describe as circumvention and your logs will describe as a user in Amsterdam.
The honest position is that you cannot guarantee territorial exclusivity by IP alone. Pretending otherwise in a contract negotiation stores up a problem.
You can layer signals, keep the enforcement decision auditable, and be able to demonstrate reasonable measures rather than perfect ones. Billing address, payment instrument country, account history and device signals all contribute. The combination is considerably better than any one of them.
What matters commercially is that the rights holder knows what your enforcement actually is before they sign. That is much better than having them discover it when their monitoring finds your stream somewhere it should not be. The same argument applies to publishing the limits of anything else we build.
The measures that show whether rights are under control
We measure the parts of the system that show whether rights, expiry, takedown and reporting are working.
- Titles available today with no valid grant. Should be zero, checked continuously rather than at month end.
- Grants expiring within thirty days with no renewal or replacement recorded.
- Titles with a grant that starts within seven days and no asset ready.
- Time from takedown decision to unavailable at the edge, measured in a drill.
- Reporting discrepancy against rights holder figures, absolute rather than percentage.
A broadcaster fixed expiry by changing the model
A broadcaster we worked with had a recurring compliance issue: two or three titles a month remained available briefly after a window closed. Their response had been to add a nightly job that swept for expired content. That reduced the exposure to under twenty four hours and did not eliminate it.
The real cause was that availability was a flag, set by a job. The job’s idea of the window came from a field that a scheduler updated manually when a contract was amended. Amendments arrived by email. Sometimes the field was updated a day later.
We moved availability to computed, sourced from grant records that were created when a contract was signed rather than transcribed afterwards. We also put the expiry calendar in front of the commercial team with alerts.
The nightly sweep was deleted because there was nothing left for it to find. Exposure went to zero and stayed there. The unexpected benefit was that the commercial team started spotting renewals they had been missing entirely.
The platform has to know what it is allowed to show
If your platform can tell you what it holds but cannot tell you what it is permitted to show, and why, then the compliance position depends on people remembering things. That works for a while. It stops working at exactly the scale where the consequences become expensive, and the first person to notice will not be you.
More on how we work in this sector on our media and entertainment page.
