FAST operations · Operational blueprint
How Content Ratings Work in a FAST Catalogue
A rating is not a portable truth that can be copied into every territory. In a FAST workflow it is one field in a larger delivery record, tied to a rating system, country, asset version and service policy.
Executive brief
What the operating team needs to know
Content ratings look like a small metadata field, but they sit at the junction of editorial judgement, local regulation, parental controls and partner delivery. A bare value such as PG is rarely enough. The useful record names the rating body, territory, asset version and episode, and keeps the evidence that led to the decision.
For business teams, the goal is not to create one universal rating. It is to create a reusable evidence record and then apply the right local decision. That separation lets a catalogue expand into a new market without treating an existing certificate as an automatic approval. It also makes partner rejections easier to diagnose.
Fewer feed rejections
Deliver the rating value together with the system and country expected by the receiving platform.
Faster territory review
Reuse timecoded observations while keeping each jurisdiction's policy decision independent.
Safer episode handling
Stop one series-level label from silently masking a stronger episode or alternate cut.
Working model
Principles before process
Use these principles to shape the record, then follow the blueprint below for the hand-off.
Start with the receiving platform's schema
Platform specifications differ. Plex's published FAST catalogue specification, for example, models ratings as a list and asks for the country, rating value and rating body. That is a useful reminder that “PG” without its system and territory is incomplete metadata.
Keep the platform's required fields separate from your internal editorial record. The delivery feed may need a compact value; the team still needs to know which exact cut, episode and language version was reviewed.
Do not convert ratings mechanically
US film ratings, television ratings and national classification systems were built for different services and audiences. A lookup table can support research, but it should not silently turn one certificate into another jurisdiction's decision.
For a series, work at episode level. Content intensity can move sharply between episodes, and a trailer, dubbed version or edited airline cut may require its own review.
Connect the label to evidence and controls
A useful operations record links the rating or advisory to the scenes that drove it. It also records the available PIN, parental-lock or age-verification controls. That makes the record reviewable when a platform changes policy or a new territory is added.
Model a rating as a decision record
Treat the combination of rating value, rating body and territory as the minimum identity. Add the asset identifier, version, runtime, language and review date so another operator can tell exactly what was assessed. If the platform accepts only a compact value, retain the richer record internally and map it at export time.
Keep the source of the rating explicit. An official classification, a distributor-supplied certificate, an internal editorial recommendation and an automated preliminary signal are not interchangeable. Operations should be able to see which one they are delivering.
- Store the certificate or decision reference where licensing permits.
- Record whether the label is official, supplied, inferred or pending.
- Make the source and last-verified date visible to downstream teams.
Use episode and version inheritance carefully
A season label can be a browsing aid, but it should not erase episode-level decisions. Build inheritance so that an episode may use the approved series default only when no stronger episode decision exists. The episode URL and delivery identifier should resolve to the same underlying asset record.
The same rule applies to edits. A broadcast cut, airline cut, dubbed track or censored version can change intensity, context and runtime. Link related versions, but do not copy the earlier approval unless the reviewer has confirmed equivalence.
Design the viewer control at the same time
A rating is useful only when the product knows what to do with it. Define how the label appears, which descriptors accompany it, whether a PIN or profile restriction applies, and what happens when a rating is missing. The fallback should be an explicit review or availability rule, not an invisible default to unrestricted access.
Test the full path in staging: catalogue ingest, storefront display, parental control, playback and reporting. A correct source record can still fail if the client application drops the rating body or displays the wrong territory label.
Reference architecture
The operating blueprint
Each stage has an owner and a concrete output. That makes failed hand-offs visible before launch.
- 01Content operations
Lock the asset
Confirm title, episode, cut, runtime, audio and subtitle languages.
Output · Versioned asset record - 02Rights and metadata
Collect provenance
Capture certificates, partner-supplied values and the territory each value covers.
Output · Source-backed rating set - 03Editorial standards
Review gaps
Inspect unrated versions and episodes using timecoded evidence and current guidance.
Output · Decision or escalation - 04Distribution engineering
Map the partner feed
Translate the approved record into the receiving schema without discarding provenance.
Output · Validated delivery payload - 05Product QA
Test controls
Verify labels, descriptors, PIN rules and restricted-profile behaviour in the client.
Output · Playback acceptance evidence - 06Catalogue governance
Monitor change
Re-open the record when the asset, policy, market or partner specification changes.
Output · Auditable revision history
Decision map
What to do when the record is not clean
Common situations, a practical next move, and the reason the shortcut fails.
| Situation | Recommended move | Why |
|---|---|---|
| The feed contains PG but no country or body | Hold or enrich the field before delivery | The same label can belong to different systems. |
| A series has one certificate and mixed episode intensity | Publish episode decisions and use the series value only as a bounded default | A stronger episode needs its own viewer protection. |
| A new dubbed or edited version arrives | Run a version-delta review | Dialogue, edits and runtime can alter the decision. |
| The destination has no accepted equivalent | Escalate to the local classification or partner workflow | A conversion table is research support, not authority. |
Failure modes
Patterns worth stopping early
These are operating defects, not writing problems. Fix the record or workflow at the source.
The orphan label
A rating value exists with no system, territory or source.
Quarantine it from automatic export and restore provenance.The season shortcut
Every episode inherits one value even when evidence varies.
Create episode overrides and expose their own canonical records.The invisible fallback
Missing ratings behave as unrestricted content.
Set an explicit hold, review or restricted-access policy.The stale certificate
A later cut keeps the original version's approval.
Compare runtimes and fingerprints, then review the changed material.Evidence example
What a review record looks like
One published example from the catalogue—not a rule or template answer for another asset.
Practical questions
What teams ask during implementation
Short answers for the decisions most likely to slow a release or partner hand-off.
Can one global age rating be used everywhere?
No single label has universal authority. Keep a common evidence record, then store the decision accepted for each territory, service and asset version.
Should a series page carry a rating?
It may show a series-level summary, but the operational source of truth should preserve episode-level exceptions and link them to stable episode URLs.
Can an automated review assign the final rating?
Automation can surface likely issues and support consistency. Official classification and broadcaster-facing approval still depend on the applicable authority, partner and qualified human review.
What should happen when a partner changes its schema?
Update the export mapping, test it against partner validation, and keep the internal decision record unchanged unless the policy—not only the field name—also changed.
Primary references
Check the current official guidance
Rules and platform specifications change. Follow the current source for the intended territory and service.
Continue the review
Use the blueprint with live evidence
Move from the operating model into market, issue, brand and title records.