Changes, Versioning, and Notifications Policy - Play258
ID: PLAY258-CHANGE | Version: 1.0.0 | Effective: 05-04-2026
Base audience: all (with segmented notifications per §5)
1. Purpose
Define how the Operator changes legal and policy documents, versions them, maintains history, classifies changes, determines new acceptance vs simple notice, and notifies each audience (Artists, Radio stations, Listeners, Organizations) proportionally — inspired by large technology platform practices, adapted to the Play258 ecosystem.
2. Covered documents
All files listed in the legal README, including GTUs, Privacy, Cookies, IP, Annexes A–D, Moderation, Reports, Retention.
3. Versioning
3.1. Semantic format per document
MAJOR.MINOR.PATCH
| Increment | When |
|---|---|
| MAJOR | Material change reducing rights, substantially increasing obligations, changing contract object, or requiring new legal consent. |
| MINOR | Addition of relevant section, new data purpose, new critical sub-processor, or significant operational change. |
| PATCH | Editorial corrections, clarifications without new legal effect, link fixes, typos, translation. |
3.2. Legal package ID (coordinated release)
To align marketing and product communication: PLAY258-LEGAL-YYYY-MM + optional release tag for coordinated publication.
3.3. Mandatory history
- Public changelog (§8) at https://play258.com/legal/changelog.
- Versions: retained by the Operator with auditable history.
- Internal record: release ticket with: documents changed, classification, affected audiences, effective date, acceptance requirement.
4. Change classification
4.1. Material
Affects essential rights/duties (e.g. invasive new data uses, sharing with new recipient categories, more restrictive liability limitation, change of venue/applicable law where permitted, new mandatory fees).
- New acceptance: often yes (where legally required or good contractual practice).
- Notification: all affected audiences.
4.2. Relevant (non-material)
Moderately affects operations or privacy (e.g. new non-essential analytics cookie, retention extension within already communicated range, new support channel).
- New acceptance: per law (consent) or notice with objection.
- Notification: affected audiences + general site notice.
4.3. Regulatory
Adaptation to new law or authority.
- New acceptance: if law requires.
- Notification: broad; shortened deadline possible (§7.3).
4.4. Editorial / technical
Clarification, reorganization, linguistic correction, URL updates.
- New acceptance: typically no.
- Notification: changelog publication; optional light banner.
5. Who to notify (segmentation)
| Scope of change | Audience to notify |
|---|---|
| Artist flow only (e.g. work reporting) | Artists with active Account |
| Radio only (e.g. playout sync policy) | Radio Account holders + designated admins |
| Listener only (e.g. transactional SMS) | Optional: general notice + users with Account; without account, public policy may suffice unless law requires otherwise |
| Organization only (e.g. IO format) | Organization Account users |
| Privacy (new bases/purposes) | All affected data subjects or all registered users + banner |
| General GTUs | All registered users + visitors via banner |
Golden rule: notify the minimum set needed for understanding and compliance, without omitting anyone who loses a right or gains a new obligation.
6. Notification channels (by priority)
- Email to verified Account address.
- In-app / dashboard notification persistent until acknowledgment (for changes requiring reading).
- Push (mobile app) as reinforcement, not sole proof.
- SMS only for urgent service or legal changes short (with link).
- Banner on website and playout login.
- RSS / changelog feed for transparency (optional).
Proof of delivery: email/push logs, acceptance timestamp in database, or dashboard view log when required.
7. Timeframes
7.1. Minimum advance notice (default)
- Material / relevant (contract): minimum 15 days before effective date, unless legally excepted.
- Urgent regulatory: per legal requirement or as soon as possible with documented justification.
- Editorial: immediate on publication or next release cycle.
7.2. Effective date
Always stated in document header and changelog (effective_date). Coexistence period for deprecated API versions may apply.
7.3. Exceptions (urgency)
- security risk;
- court or administrative order;
- termination of critical sub-processor;
- correction restoring user rights (may be immediate).
8. Transparent changelog model (“what changed”)
Each entry should contain:
## [PLAY258-TGU] 1.1.0 - 2026-04-01
**Type:** Relevant | **Acceptance required:** Yes (registered users)
**Affects:** all
### Summary for users
- Clearer language.
### Legal detail
- Section X: ...
### What does not change
- ...
Suggested publication at https://play258.com/legal/changelog (create or update on first relevant change).
9. New acceptance mechanism
9.1. Interstitial at login or block critical features until accept or decline (decline may mean termination).
9.2. Record account identification, document and version accepted, acceptance time and, where applicable, technical data permitted by law (e.g. IP summary), and language.
9.3. For minors, parental flow if applicable.
10. Consistency across documents
Annex changes must not contradict GTUs; if needed, update cross-references in the same release (same package ID).
11. Contact
info@voneka.co.mz | dpo@voneka.co.mz
Operational policy — align minimum notice periods with local counsel.